From adrian@olddog.co.uk Wed Aug 1 17:37: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 1485311E8193; Wed, 1 Aug 2012 17:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiyvBH4gN8Ww; Wed, 1 Aug 2012 17:37:24 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 638CD11E8106; Wed, 1 Aug 2012 17:37:23 -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 q720bLGU005141; Thu, 2 Aug 2012 01:37:21 +0100 Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q720bCxB005108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 01:37:16 +0100 From: "Adrian Farrel" To: , , Date: Thu, 2 Aug 2012 01:37:10 +0100 Message-ID: <002f01cd7046$f816d540$e8447fc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CD704F.59E26930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1wRvAhydNOH6pRTm2rrkOOgu3Uvw== Content-Language: en-gb Subject: [RTG-DIR] LOCATION CHANGE : Routing Area Open Meeting 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, 02 Aug 2012 00:37:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0030_01CD704F.59E26930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We decided we might need a larger room given the IRS discussion, so we have moved to Regency D. Signs will be posted. Cheers, Adrian From: 84all-bounces@ietf.org [mailto:84all-bounces@ietf.org] On Behalf Of Wanda Lo Sent: 02 August 2012 00:45 To: 84all@ietf.org Subject: [84all] 84 Agenda Change Please note the following changes on your printed pocket agenda: August 2, 2012 Thursday 0900-1130 Morning Session I Regency D RTG rtgarea Routing Area Open Meeting - Room changed FROM Regency E TO Regency D Once again, the web agenda is always most up to date, https://datatracker.ietf.org/meeting/84/agenda.txt. Thanks, Wanda =========================== Wanda Lo / Project Manager Internet Engineering Task Force (IETF) 48377 Fremont Blvd., Ste. 117 Fremont, California 94538 / USA T: +1.510.492.4082 F: +1.510.492.4001 www.ietf.org -- Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com ------=_NextPart_000_0030_01CD704F.59E26930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We decided we might need a = larger room given the IRS discussion, so we have moved to Regency = D.

 

Signs will be = posted.

 

Cheers,

Adrian

 

From: = 84all-bounces@ietf.org [mailto:84all-bounces@ietf.org] On Behalf Of = Wanda Lo
Sent: 02 August 2012 00:45
To: = 84all@ietf.org
Subject: [84all] 84 Agenda = Change

 

Please note the = following changes on your printed pocket = agenda:

 

August 2, 2012 Thursday

0900-1130 Morning = Session I

Regency D  RTG    rtgarea        = ;    Routing Area Open = Meeting - Room changed FROM Regency E TO Regency = D

 

 

<= p class=3DMsoNormal>Once again, the web agenda is always most up to = date, https://datat= racker.ietf.org/meeting/84/agenda.txt.

 

 

Thanks,

Wanda

<= /div>

 

 

 

 

=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

Wanda Lo / Project = Manager

Internet Engineering Task Force = (IETF)

48377 Fremont Blvd., Ste. = 117 
Fremont, California 94538 / USA T: +1.510.492.4082
F: +1.510.492.4001 
www.ietf.org

 

--

Managed by Association = Management Solutions (AMS)

Forum Management, Meeting and = Event Planning

 



 

------=_NextPart_000_0030_01CD704F.59E26930-- From adrian@olddog.co.uk Thu Aug 2 12:34: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 BBBA611E8103; Thu, 2 Aug 2012 12:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfJUruNmgXm5; Thu, 2 Aug 2012 12:34:11 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 99DD811E80D2; Thu, 2 Aug 2012 12:34:11 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72JYA9T023472; Thu, 2 Aug 2012 20:34:10 +0100 Received: from 950129200 (dhcp-43f4.meeting.ietf.org [130.129.67.244]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q72JY3HS023433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 20:34:07 +0100 From: "Adrian Farrel" To: , References: In-Reply-To: Date: Thu, 2 Aug 2012 20:34:01 +0100 Message-ID: <019101cd70e5$c949c890$5bdd59b0$@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: AQDAKN99HAnewsF8LrKkT0Uzm+8mQplheMiw Content-Language: en-gb Cc: dhc-chairs@tools.ietf.org, dhc-ads@toools.ietf.org Subject: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 02 Aug 2012 19:34:12 -0000 Hi, At the Routing Area meeting this morning, Ted raised some potential DHCP work that routing folk should look at. Comments ideally go to the DHC working group or back to Ted. Adrian > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: 02 August 2012 20:11 > To: adrian@olddog.co.uk > Subject: DHCPv6 Prefix Pool Option > > Thanks for the time at the mic this morning. The document I wanted you to > comment on or solicit comment on is the DHCPv6 Prefix Pool Option draft: > > http://tools.ietf.org/html/draft-yeh-dhc-dhcpv6-prefix-pool-opt > > There was a question at the mic about why the DHCP server wouldn't inject the > route itself, which I think is a good question, and could be argued to be the right > thing to do. However, operationally there are a lot of missing pieces to this-the > DHCP server now becomes, in addition to being a DHCP server, also a publisher of > routes, and has to have information about the routing topology of the ISP that I > think might be nontrivial to maintain. > > The advantage of the current approach, which is improved by this new draft, is > that it piggybacks on top of the existing relationship between the relay agent and > the DHCP server, which is required for DHCP to work. The DHCP server now > does not have to know the topology of the network-it sends the prefix > aggregation information to the router, which presumably already has that > information, by way of the DHCP relay, which is typically co-located in the router. > > So despite my protestations of innocence at the mic, I suppose I do really think > it's a reasonable way to solve this particular problem. From acee.lindem@ericsson.com Thu Aug 2 12:47: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 9D1FF11E8186; Thu, 2 Aug 2012 12:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lUL6u-fxyik; Thu, 2 Aug 2012 12:47:51 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8500B11E8183; Thu, 2 Aug 2012 12:47:51 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q72JlgBl018854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 14:47:43 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 2 Aug 2012 15:47:42 -0400 From: Acee Lindem To: "adrian@olddog.co.uk" Date: Thu, 2 Aug 2012 15:47:41 -0400 Thread-Topic: [RTG-DIR] DHCPv6 Prefix Pool Option Thread-Index: Ac1w561/kXUjIXr1QZK45tR8C15Axg== Message-ID: <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> In-Reply-To: <019101cd70e5$c949c890$5bdd59b0$@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-54-557441424"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "dhc-chairs@tools.ietf.org" , Ted Lemon , "dhc-ads@toools.ietf.org" , "routing-discussion@ietf.org" Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 02 Aug 2012 19:47:52 -0000 --Apple-Mail-54-557441424 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'm not sure what I was thinking this morning when I said that the DHCP = server should run a routing daemon and advertise the aggregate route. = Rather, the BRAS server that is maintaining subscriber DHCP state should = have a configured aggregation policy for the DHCP prefix pool route. = This problem has already been solved in commercial BRAS servers and = there is no need to add a generic route advertisement mechanism to DHCP.=20= Thanks, Acee On Aug 2, 2012, at 3:34 PM, Adrian Farrel wrote: > Hi, >=20 > At the Routing Area meeting this morning, Ted raised some potential = DHCP work > that routing folk should look at. Comments ideally go to the DHC = working group > or back to Ted. >=20 > Adrian >=20 >> -----Original Message----- >> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >> Sent: 02 August 2012 20:11 >> To: adrian@olddog.co.uk >> Subject: DHCPv6 Prefix Pool Option >>=20 >> Thanks for the time at the mic this morning. The document I wanted = you to >> comment on or solicit comment on is the DHCPv6 Prefix Pool Option = draft: >>=20 >> http://tools.ietf.org/html/draft-yeh-dhc-dhcpv6-prefix-pool-opt >>=20 >> There was a question at the mic about why the DHCP server wouldn't = inject the >> route itself, which I think is a good question, and could be argued = to be the > right >> thing to do. However, operationally there are a lot of missing = pieces to > this-the >> DHCP server now becomes, in addition to being a DHCP server, also a = publisher > of >> routes, and has to have information about the routing topology of the = ISP that > I >> think might be nontrivial to maintain. >>=20 >> The advantage of the current approach, which is improved by this new = draft, is >> that it piggybacks on top of the existing relationship between the = relay agent > and >> the DHCP server, which is required for DHCP to work. The DHCP = server now >> does not have to know the topology of the network-it sends the prefix >> aggregation information to the router, which presumably already has = that >> information, by way of the DHCP relay, which is typically co-located = in the > router. >>=20 >> So despite my protestations of innocence at the mic, I suppose I do = really > think >> it's a reasonable way to solve this particular problem. >=20 --Apple-Mail-54-557441424 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgwMjE5NDc0MVowIwYJKoZI hvcNAQkEMRYEFKKA1rIVNr9bbG5ILOyjbQKDD7EPMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgF7Qp9a1iCVBcOdsG4hciLYcA9p70QC2awmHCLWGFg1907Y+seacJfujcJi1KKrn CxRFfBdZ2aGIVR4NiGR30zYSzPunRZIXOMD0KVet6kybQjIzn+Iyaw2/+2PJP20habRjnaFL0bkX 1ISHeIhGy7CYI5Bex3mpwwS7ZsgIoWYfAAAAAAAA --Apple-Mail-54-557441424-- From acee.lindem@ericsson.com Fri Aug 3 10:54:58 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 2A35E21F8E15; Fri, 3 Aug 2012 10:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vLgw+VloHst; Fri, 3 Aug 2012 10:54:57 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB1721F8E01; Fri, 3 Aug 2012 10:54:56 -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 q73HsmM5000554; Fri, 3 Aug 2012 12:54:51 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 3 Aug 2012 13:54:49 -0400 From: Acee Lindem To: Ted Lemon Date: Fri, 3 Aug 2012 13:54:48 -0400 Thread-Topic: [RTG-DIR] DHCPv6 Prefix Pool Option Thread-Index: Ac1xoRMtxvtylRWASmabWeAcb4ZH+w== Message-ID: References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-71-634375523"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "dhc-chairs@tools.ietf.org Chairs" , "" , "routing-discussion@ietf.org" Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 03 Aug 2012 17:54:59 -0000 --Apple-Mail-71-634375523 Content-Type: multipart/alternative; boundary=Apple-Mail-70-634375508 --Apple-Mail-70-634375508 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I'm sorry but it doesn't work this way at all. The BRAS server will = advertise the aggregate if it has any component of the aggregate prefix = and the BRAS server will know better than the DHCP server as to whether = it has any subscribers within the range subsumed by the aggregate route = Any concerns with sub-optimal or routing are independent of whether the = policy is in the DHCP server or BRAS router.=20 On Aug 2, 2012, at 6:15 PM, Ted Lemon wrote: > On Aug 2, 2012, at 12:47 PM, Acee Lindem wrote: >> I'm not sure what I was thinking this morning when I said that the = DHCP server should run a routing daemon and advertise the aggregate = route. Rather, the BRAS server that is maintaining subscriber DHCP state = should have a configured aggregation policy for the DHCP prefix pool = route. This problem has already been solved in commercial BRAS servers = and there is no need to add a generic route advertisement mechanism to = DHCP.=20 >=20 > Has the problem really been solved? It seems to me that the BRAS has = a limited capability to aggregate prefixes=97it can only aggregate a = group of prefixes when all of the prefixes that are members of that = prefix have been assigned. So if you have a DHCP server doing a fairly = random allocation of prefixes out of an aggregate pool to a particular = BRAS, in general the BRAS is not going to be able to advertise a route = to the larger prefix, but rather only to smaller prefixes. It may be = able to reduce the routing table somewhat by combining adjacent = prefixes, but it will never be able to advertise the actual prefix from = which CPE prefixes are being allocated, because it can't know what that = prefix is until every single prefix within it has been assigned. >=20 > Furthermore, as soon as a single prefix from within that prefix = expires, the BRAS has to break apart the prefixes it is advertising. = And this has to be done carefully to avoid attracting routes that are no = longer configured on the BRAS=97it has to be done _before_ the prefix = expires. Whereas if the BRAS can be told "all your routes will be = coming out of this prefix," then it can just continually advertise the = same prefix, regardless of the comings and goings of DHCP requesting = routers and the prefixes that are assigned to them. >=20 --Apple-Mail-70-634375508 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I'm = sorry but it doesn't work this way at all. The BRAS server will = advertise the aggregate if it has any component of the aggregate prefix = and the BRAS server will know better than the DHCP server as to whether = it has any subscribers within the range subsumed by the aggregate route =  Any concerns with sub-optimal or routing are independent of = whether the policy is in the DHCP server or BRAS = router. 
On Aug 2, 2012, at 6:15 PM, Ted Lemon = wrote:

On Aug 2, = 2012, at 12:47 PM, Acee Lindem wrote:
I'm not sure = what I was thinking this morning when I said that the DHCP server should = run a routing daemon and advertise the aggregate route. Rather, the BRAS = server that is maintaining subscriber DHCP state should have a = configured aggregation policy for the DHCP prefix pool route. This = problem has already been solved in commercial BRAS servers and there is = no need to add a generic route advertisement mechanism to DHCP. 

Has the problem really been solved?   It seems to me that = the BRAS has a limited capability to aggregate prefixes=97it can only = aggregate a group of prefixes when all of the prefixes that are members = of that prefix have been assigned.   So if you have a DHCP server = doing a fairly random allocation of prefixes out of an aggregate pool to = a particular BRAS, in general the BRAS is not going to be able to = advertise a route to the larger prefix, but rather only to smaller = prefixes.   It may be able to reduce the routing table somewhat by = combining adjacent prefixes, but it will never be able to advertise the = actual prefix from which CPE prefixes are being allocated, because it = can't know what that prefix is until every single prefix within it has = been assigned.

Furthermore, as soon as a single = prefix from within that prefix expires, the BRAS has to break apart the = prefixes it is advertising.   And this has to be done carefully to = avoid attracting routes that are no longer configured on the BRAS=97it = has to be done _before_ the prefix expires.   Whereas if the BRAS = can be told "all your routes will be coming out of this prefix," then it = can just continually advertise the same prefix, regardless of the = comings and goings of DHCP requesting routers and the prefixes that are = assigned to = them.


= --Apple-Mail-70-634375508-- --Apple-Mail-71-634375523 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgwMzE3MDk1NlowIwYJKoZI hvcNAQkEMRYEFBrWwcDfOKugo27pzVPBJVuSfBIxMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgB0BtNF97AS5zANGSdkccpznGs+iXeE8kVrcxtm8NdwAMpeIMkkP5xB1UQF5gLAu FAwkvzuu7gvLLO4XateUpJR6RzbD/U7whCsyUQorEYVkz4Mia3Q24MYX71y++XCVTX3XdFLQaMzk GVI45jtbWuAvxUST0n0S6B1d7GIA6oLpAAAAAAAA --Apple-Mail-71-634375523-- From mellon@fugue.com Thu Aug 2 15:15:14 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 B844121E80C2; Thu, 2 Aug 2012 15:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sR8sgknZGH2; Thu, 2 Aug 2012 15:15:13 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id BF08921E8090; Thu, 2 Aug 2012 15:15:13 -0700 (PDT) Received: from [IPv6:2001:df8::64:f1a3:6155:c937:1c0c] (unknown [IPv6:2001:df8:0:64:f1a3:6155:c937:1c0c]) by toccata.fugue.com (Postfix) with ESMTPSA id A25CF23814C2; Thu, 2 Aug 2012 18:15:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D3450915-AAF5-4DB5-BA07-23E538258EF5" From: Ted Lemon In-Reply-To: <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> Date: Thu, 2 Aug 2012 15:15:10 -0700 Message-Id: References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> To: Acee Lindem X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Fri, 03 Aug 2012 11:55:59 -0700 Cc: rtg-dir@ietf.org, "dhc-chairs@tools.ietf.org Chairs" , "" , routing-discussion@ietf.org Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 02 Aug 2012 22:15:14 -0000 --Apple-Mail=_D3450915-AAF5-4DB5-BA07-23E538258EF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 2, 2012, at 12:47 PM, Acee Lindem wrote: > I'm not sure what I was thinking this morning when I said that the = DHCP server should run a routing daemon and advertise the aggregate = route. Rather, the BRAS server that is maintaining subscriber DHCP state = should have a configured aggregation policy for the DHCP prefix pool = route. This problem has already been solved in commercial BRAS servers = and there is no need to add a generic route advertisement mechanism to = DHCP.=20 Has the problem really been solved? It seems to me that the BRAS has a = limited capability to aggregate prefixes=97it can only aggregate a group = of prefixes when all of the prefixes that are members of that prefix = have been assigned. So if you have a DHCP server doing a fairly random = allocation of prefixes out of an aggregate pool to a particular BRAS, in = general the BRAS is not going to be able to advertise a route to the = larger prefix, but rather only to smaller prefixes. It may be able to = reduce the routing table somewhat by combining adjacent prefixes, but it = will never be able to advertise the actual prefix from which CPE = prefixes are being allocated, because it can't know what that prefix is = until every single prefix within it has been assigned. Furthermore, as soon as a single prefix from within that prefix expires, = the BRAS has to break apart the prefixes it is advertising. And this = has to be done carefully to avoid attracting routes that are no longer = configured on the BRAS=97it has to be done _before_ the prefix expires. = Whereas if the BRAS can be told "all your routes will be coming out of = this prefix," then it can just continually advertise the same prefix, = regardless of the comings and goings of DHCP requesting routers and the = prefixes that are assigned to them. --Apple-Mail=_D3450915-AAF5-4DB5-BA07-23E538258EF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I'm not sure = what I was thinking this morning when I said that the DHCP server should = run a routing daemon and advertise the aggregate route. Rather, the BRAS = server that is maintaining subscriber DHCP state should have a = configured aggregation policy for the DHCP prefix pool route. This = problem has already been solved in commercial BRAS servers and there is = no need to add a generic route advertisement mechanism to DHCP. 

Has the problem really been solved?   It seems to me that = the BRAS has a limited capability to aggregate prefixes=97it can only = aggregate a group of prefixes when all of the prefixes that are members = of that prefix have been assigned.   So if you have a DHCP server = doing a fairly random allocation of prefixes out of an aggregate pool to = a particular BRAS, in general the BRAS is not going to be able to = advertise a route to the larger prefix, but rather only to smaller = prefixes.   It may be able to reduce the routing table somewhat by = combining adjacent prefixes, but it will never be able to advertise the = actual prefix from which CPE prefixes are being allocated, because it = can't know what that prefix is until every single prefix within it has = been assigned.

Furthermore, as soon as a single = prefix from within that prefix expires, the BRAS has to break apart the = prefixes it is advertising.   And this has to be done carefully to = avoid attracting routes that are no longer configured on the BRAS=97it = has to be done _before_ the prefix expires.   Whereas if the BRAS = can be told "all your routes will be coming out of this prefix," then it = can just continually advertise the same prefix, regardless of the = comings and goings of DHCP requesting routers and the prefixes that are = assigned to them.

= --Apple-Mail=_D3450915-AAF5-4DB5-BA07-23E538258EF5-- From mellon@fugue.com Mon Aug 6 06:28: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 1DDEC21F869D; Mon, 6 Aug 2012 06:28:00 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s+975s9+Lsg; Mon, 6 Aug 2012 06:27:59 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 254EE21F869C; Mon, 6 Aug 2012 06:27:59 -0700 (PDT) Received: from agape-4.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 1E20B2380630; Mon, 6 Aug 2012 09:27:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3585F883-466F-409D-9CFC-35BCA82F61B9" From: Ted Lemon In-Reply-To: Date: Mon, 6 Aug 2012 09:27:56 -0400 Message-Id: <3E00A188-D7F9-44AD-A9A7-DF49BE6484AF@fugue.com> References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> To: Acee Lindem X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Mon, 06 Aug 2012 09:42:16 -0700 Cc: "rtg-dir@ietf.org" , "dhc-chairs@tools.ietf.org Chairs" , "" , "routing-discussion@ietf.org" Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 06 Aug 2012 13:28:00 -0000 --Apple-Mail=_3585F883-466F-409D-9CFC-35BCA82F61B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 3, 2012, at 1:54 PM, Acee Lindem wrote: > I'm sorry but it doesn't work this way at all. The BRAS server will = advertise the aggregate if it has any component of the aggregate prefix = and the BRAS server will know better than the DHCP server as to whether = it has any subscribers within the range subsumed by the aggregate route = Any concerns with sub-optimal or routing are independent of whether the = policy is in the DHCP server or BRAS router.=20 As far as I can tell, you are referring to the case where the BRAS has = been allocated a prefix, and is acting as a DHCP server. What you say = doesn't really make sense if the BRAS is not the DHCP server. The = whole point of Leaf's draft, as I understand it (perhaps Leaf can jump = in and correct me if I get it wrong) is to allow the DHCP server to be = responsible for prefix allocation, and pull that intelligence out of the = BRAS. This allows for more flexibility than is possible if each BRAS = has to be configured as a DHCP server with a fixed prefix from which to = do allocations. Also, Leaf's solution works generally for provider edge routers without = requiring the heavyweight functionality of a BRAS=97ultimately, for a = straight IPv6 routed network with no PPP tunnels, the PE router can be = _much_ simpler using prefix pool allocation than using the configuration = technique you are describing. --Apple-Mail=_3585F883-466F-409D-9CFC-35BCA82F61B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I'm sorry but = it doesn't work this way at all. The BRAS server will advertise the = aggregate if it has any component of the aggregate prefix and the BRAS = server will know better than the DHCP server as to whether it has any = subscribers within the range subsumed by the aggregate route  Any = concerns with sub-optimal or routing are independent of whether the = policy is in the DHCP server or BRAS = router. 

As far as I can tell, = you are referring to the case where the BRAS has been allocated a = prefix, and is acting as a DHCP server.   What you say doesn't = really make sense if the BRAS is not the DHCP server.   The whole = point of Leaf's draft, as I understand it (perhaps Leaf can jump in and = correct me if I get it wrong) is to allow the DHCP server to be = responsible for prefix allocation, and pull that intelligence out of the = BRAS.   This allows for more flexibility than is possible if each = BRAS has to be configured as a DHCP server with a fixed prefix from = which to do allocations.

Also, Leaf's solution = works generally for provider edge routers without requiring the = heavyweight functionality of a BRAS=97ultimately, for a straight IPv6 = routed network with no PPP tunnels, the PE router can be _much_ simpler = using prefix pool allocation than using the configuration technique you = are describing.

= --Apple-Mail=_3585F883-466F-409D-9CFC-35BCA82F61B9-- From leaf.y.yeh@huawei.com Tue Aug 7 04:07: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 EAB8021F85DB; Tue, 7 Aug 2012 04:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pav2TEPqFHq3; Tue, 7 Aug 2012 04:07:10 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C54E121F85DA; Tue, 7 Aug 2012 04:07:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIP06339; Tue, 07 Aug 2012 03:07:09 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 04:05:29 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 7 Aug 2012 04:05:28 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Tue, 7 Aug 2012 19:05:20 +0800 From: Leaf yeh To: Ted Lemon , Acee Lindem Thread-Topic: [RTG-DIR] DHCPv6 Prefix Pool Option Thread-Index: AQHNc9dJ9dYDWKvg6U6z8H0vqwSvwpdOLNGw Date: Tue, 7 Aug 2012 11:05:19 +0000 Message-ID: References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> <3E00A188-D7F9-44AD-A9A7-DF49BE6484AF@fugue.com> In-Reply-To: <3E00A188-D7F9-44AD-A9A7-DF49BE6484AF@fugue.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: multipart/alternative; boundary="_000_E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C452A99SZXEML510MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 07 Aug 2012 14:04:01 -0700 Cc: "rtg-dir@ietf.org" , "dhc-chairs@tools.ietf.org Chairs" , "" , "routing-discussion@ietf.org" Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 07 Aug 2012 11:07:12 -0000 --_000_E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C452A99SZXEML510MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In general speaking, draft (OPTION_PREFIX_POOL) targets the use case when P= E router (or BNG in BBF model) acts as the relay, and the centralized DHCPv= 6 server maintains the information about the prefix delegation pools. Best Regards, Leaf From: routing-discussion-bounces@ietf.org [mailto:routing-discussion-bounce= s@ietf.org] On Behalf Of Ted Lemon Sent: Monday, August 06, 2012 9:28 PM To: Acee Lindem Cc: rtg-dir@ietf.org; dhc-chairs@tools.ietf.org Chairs; ; routing-discussion@ietf.org Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option On Aug 3, 2012, at 1:54 PM, Acee Lindem wrote: I'm sorry but it doesn't work this way at all. The BRAS server will adverti= se the aggregate if it has any component of the aggregate prefix and the BR= AS server will know better than the DHCP server as to whether it has any su= bscribers within the range subsumed by the aggregate route Any concerns wi= th sub-optimal or routing are independent of whether the policy is in the D= HCP server or BRAS router. As far as I can tell, you are referring to the case where the BRAS has been= allocated a prefix, and is acting as a DHCP server. What you say doesn't= really make sense if the BRAS is not the DHCP server. The whole point of= Leaf's draft, as I understand it (perhaps Leaf can jump in and correct me = if I get it wrong) is to allow the DHCP server to be responsible for prefix= allocation, and pull that intelligence out of the BRAS. This allows for = more flexibility than is possible if each BRAS has to be configured as a DH= CP server with a fixed prefix from which to do allocations. Also, Leaf's solution works generally for provider edge routers without req= uiring the heavyweight functionality of a BRAS-ultimately, for a straight I= Pv6 routed network with no PPP tunnels, the PE router can be _much_ simpler= using prefix pool allocation than using the configuration technique you ar= e describing. --_000_E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C452A99SZXEML510MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In general= speaking, draft (OPTION_PREFIX_POOL) targets the use case when PE router (= or BNG in BBF model) acts as the relay, and the centralized DHCPv6 server maintains the information about the prefix delegation pools.=

 = ;

 = ;

Best Regards,

Leaf

 = ;

 = ;

From: routing-discussion-bounces@ietf.org [mailto:routing-d= iscussion-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Monday, August 06, 2012 9:28 PM
To: Acee Lindem
Cc: rtg-dir@ietf.org; dhc-chairs@tools.ietf.org Chairs; <dhc-ads@= tools.ietf.org>; routing-discussion@ietf.org
Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option

 

On Aug 3, 2012, at 1:54 PM, Ace= e Lindem wrote:

I'm sorry but it doesn't work this way at all. The BRAS server w= ill advertise the aggregate if it has any component of the aggregate prefix and the BRAS server will know better than the DHCP server as to whe= ther it has any subscribers within the range subsumed by the aggregate rout= e  Any concerns with sub-optimal or routing are independent of whether= the policy is in the DHCP server or BRAS router. 

 

As far as I can tell, you are r= eferring to the case where the BRAS has been allocated a prefix, and is act= ing as a DHCP server.   What you say doesn't really make sense if the = BRAS is not the DHCP server.   The whole point of Leaf's draft, as I understand it (perhaps Leaf can jump in and co= rrect me if I get it wrong) is to allow the DHCP server to be responsible f= or prefix allocation, and pull that intelligence out of the BRAS.   Th= is allows for more flexibility than is possible if each BRAS has to be configured as a DHCP server with a fixed p= refix from which to do allocations.

 

Also, Leaf's solution works gen= erally for provider edge routers without requiring the heavyweight function= ality of a BRAS—ultimately, for a straight IPv6 routed network with n= o PPP tunnels, the PE router can be _much_ simpler using prefix pool allocation than using the configuration techniqu= e you are describing.

 

--_000_E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C452A99SZXEML510MBSchi_-- From mellon@fugue.com Fri Aug 10 05:50:38 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 526C221F84F1; Fri, 10 Aug 2012 05:50:38 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNIjlFHogZYr; Fri, 10 Aug 2012 05:50:37 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A6C5521F84EF; Fri, 10 Aug 2012 05:50:37 -0700 (PDT) Received: from [10.1.10.11] (173-162-214-218-NewEngland.hfc.comcastbusiness.net [173.162.214.218]) by toccata.fugue.com (Postfix) with ESMTPSA id 440802380648; Fri, 10 Aug 2012 08:50:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: Date: Fri, 10 Aug 2012 08:50:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6C2CDBAF-3F66-4B83-8697-2B073967B166@fugue.com> References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> <3E00A188-D7F9-44AD-A9A7-DF49BE6484AF@fugue.com> To: routing-discussion@ietf.org X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Fri, 10 Aug 2012 06:15:42 -0700 Cc: rtg-dir@ietf.org, Acee Lindem , "dhc-chairs@tools.ietf.org Chairs" , Leaf yeh , "" Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 10 Aug 2012 12:50:38 -0000 So, I haven't heard any discussion on this topic since I wrote a = clarifying message on August 6 about the intended use case for this = option. Does this mean that we've satisfactorily addressed the use = case question that Acee raised, and that no-one else objects, or does it = mean that everybody is taking a well-deserved break from IETF email = following the Vancouver meeting? From takeda.tomonori@lab.ntt.co.jp Fri Aug 10 08:03:09 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 DC71821F861E for ; Fri, 10 Aug 2012 08:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0BBmd3AzRbv for ; Fri, 10 Aug 2012 08:03:09 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4580221F844E for ; Fri, 10 Aug 2012 08:03:09 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q7AF37l6010147; Sat, 11 Aug 2012 00:03:07 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 9128FE0090; Sat, 11 Aug 2012 00:03:07 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 85656E008F; Sat, 11 Aug 2012 00:03:07 +0900 (JST) Received: from [IPv6:::1] (panasonic.nslab.ecl.ntt.co.jp [129.60.80.55]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id q7AF2fQM004248; Sat, 11 Aug 2012 00:03:07 +0900 Message-ID: <502522AE.1060301@lab.ntt.co.jp> Date: Sat, 11 Aug 2012 00:03:10 +0900 From: Tomonori Takeda User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja-JP; rv:1.9.2.15) Gecko/20110323 Lanikai/3.1.9 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org, draft-ietf-ccamp-rfc5787bis.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-rfc5787bis-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:03:10 -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-ccamp-rfc5787bis-05.txt Reviewer: Tomonori Takeda Review Date: 2012-08-10 IETF LC End Date: 2012-08-17 Intended Status: Proposed Standard Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document defines OSPF extensions to meet the requirements for ASON routing expressed in RFC 4258. This document obsoletes RFC 5787, which is an experimental version of OSPF extensions for ASON routing. Major Issues: None Minor Issues: None Nits: 1) In Section 4, last line, it says "refer to section 6.1", which should be "refer to section 6.2". 2) In Section 6.1, last paragraph, there are two places with "the Local and Remote ID sub-TLV", which should be "the Local and Remote TE Router ID sub-TLV". 3) In Section 11.1, 7th line, it says "with RCs in the same RC", which should be "with RCs in the same RA". 4) In Section 12, requirements from RFC 4258 are listed. I am wondering how these requirements are picked from RFC 4258. My guess is that requirements are largely from text with "MUST" "SHALL" "SHOULD" in RFC 4258, but several requirements listed in Section 12 are not clear to me. Specifically, a) Requirements #7 and #8 - I could not find corresponding text in RFC 4258. Have I missed something? b) Requirements #14 and #15 - My reading of RFC 4258 is that these are just "approaches" and not "requirements". Thanks, Tomonori From lizhong.jin@zte.com.cn Tue Aug 14 06:34: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 3871921F8682 for ; Tue, 14 Aug 2012 06:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.464 X-Spam-Level: X-Spam-Status: No, score=-101.464 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDTFqnPGybyO for ; Tue, 14 Aug 2012 06:34:40 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5A521F8674 for ; Tue, 14 Aug 2012 06:34:39 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 10723712910399; Tue, 14 Aug 2012 21:21:10 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 37064.2240368483; Tue, 14 Aug 2012 21:34:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q7EDYVaX048277; Tue, 14 Aug 2012 21:34:31 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) To: rtg-ads@tools.ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Tue, 14 Aug 2012 21:34:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-14 21:34:17, Serialize complete at 2012-08-14 21:34:17 Content-Type: multipart/alternative; boundary="=_alternative 004A90D948257A5A_=" X-MAIL: mse01.zte.com.cn q7EDYVaX048277 Cc: draft-ietf-pwe3-mpls-eth-oam-iwk.all@tools.ietf.org, rtg-dir@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 13:34:41 -0000 This is a multipart message in MIME format. --=_alternative 004A90D948257A5A_= Content-Type: text/plain; charset="US-ASCII" 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-pwe3-mpls-eth-oam-iwk-06.txt Reviewer: Lizhong Jin Review Date: Aug, 14th, 2012 IETF LC End Date: Aug, 20th, 2012 Intended Status: Standard track Summary: 1.I have some minor concerns about this document that I think should be resolved before publication. Comments: Basically, this document is well written and I believe the mechanism has been implemented and deployed in real networks. There are only some parts of the document that need to be clarified to avoid misunderstanding. Major Issues: No major issues found. Minor Issues: 2.2. Abstract Defect States A PW forward defect indication received on PE1 impacts the ability of PE1 to receive traffic on the PW. [Lizhong] "PW forward defect" only refers to one mechanism above, should it be "PW receive defect"? 4.1. Use of Native Service (NS) Notification - Sending of AIS frames from the local MEP to the MEP on the remote PE when the MEP needs to convey PE receive defects, and when CCM transmission is disabled. [Lizhong] "PE receive defects" refer to PE AC receive defects or both AC and PE receive defects? - Suspension of CCM frames transmission from the local MEP to the peer MEP on the remote PE to convey PE receive defects, when CCM transmission is enabled. [Lizhong] "PE receive defects" refer to PE AC receive defects or both AC and PE receive defects? 4.2. Use of PW Status notification for MPLS PSNs There are also scenarios where a PE carries out PW label withdrawal instead of PW status notification. These include administrative disablement of the PW or loss of Target LDP session with the peer PE. [Lizhong] There is another PW/AC status signaling method by using label withdraw method when PW status notification is not supported. Is it intentionally ignored? 4.3. Use of BFD Diagnostic Codes When using VCCV, the control channel (CC) type and Connectivity Verification (CV) Type are agreed on between the peer PEs using the OAM capability sub-TLV signaled as part of the interface parameter TLV when using FEC 129 and the interface parameter sub-TLV when using FEC 128. [Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface parameters sub-TLV", right? Suggest to align with terminology in RFC5085. 5. Ethernet AC Defect States Entry or Exit Criteria [Lizhong] context of AC receive/transmit defect entry is duplicated with that in section 2.2. Is it possible to make the context more simple, either in section 2.2 or 5.1? 6. Ethernet AC and PW Defect States Interworking [Lizhong] RFC2119 words should be used in this section, e.g, "must" should be "MUST". 6.1. PW Receive Defect Entry Procedures [Lizhong] this section does not describe the mechanism to enter PW receive defect state, is it same with that in section 2.2? Further, when PE1 enters the Receive Defect state, it must assume that PE2 has no knowledge of the defect and must send reverse defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN, this is done via either a PW Status notification message indicating a reverse defect; or via VCCV-BFD diagnostic code of reverse defect if VCCV CV type of 0x08 had been negotiated. [Lizhong] why CV type of 0x20 is missed here? 6.2. PW Receive Defect Exit Procedures [Lizhong] this section does not describe the mechanism to exit PW receive defect state? If PW receive defect was established via notification from PE2 or via loss of control adjacency, no additional action is needed, since PE2 is expected to be aware of the defect clearing. [Lizhong] the above description is incorrect in this section. The exit of PW receive defect should be described, not enter of PW receive defect. 6.3. PW Transmit Defect Entry Procedures - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is used for fault notification, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Not Active. [Lizhong] shouldn't the entry of PW transmit defect be signaled to remote PE? I do not see such text here. 6.4. PW Transmit Defect Exit Procedures - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Active. [Lizhong] same comment as for previous section, shouldn't the exit of PW transmit defect be signaled to remote PE? I do not see such text here. 6.5. AC Receive Defect Entry Procedures When Native Service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 4.1. [Lizhong] is there any relationship between notification mechanism in CE domain and mechanism in PE domain. I mean if the AC uses NS OAM to detect defect in CE domain, does NS OAM between PEs have any priority to apply? Nits: There are some nits that need to resolve. Please check link: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt Regards Lizhong --=_alternative 004A90D948257A5A_= Content-Type: text/html; charset="US-ASCII"
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-pwe3-mpls-eth-oam-iwk-06.txt
Reviewer: Lizhong Jin
Review Date: Aug, 14th, 2012
IETF LC End Date: Aug, 20th, 2012
Intended Status: Standard track

Summary:
1.I have some minor concerns about this document that I think should be resolved before publication.

Comments:
Basically, this document is well written and I believe the mechanism has been implemented and deployed in real networks. There are only some parts of the document that need to be clarified to avoid misunderstanding.

Major Issues:
No major issues found.

Minor Issues:
2.2.  Abstract Defect States
A PW forward defect indication received on PE1 impacts the ability
of PE1 to receive traffic on the PW.
[Lizhong] "PW forward defect" only refers to one mechanism above, should it be "PW receive defect"?
 
4.1. Use of Native Service (NS) Notification  

    - Sending of AIS frames from the local MEP to the MEP on the
remote PE when the MEP needs to convey PE receive defects, and when
CCM transmission is disabled.  
[Lizhong] "PE receive defects" refer to PE AC receive defects or both AC and PE receive defects?
 
    - Suspension of CCM frames transmission from the local MEP to
the peer MEP on the remote PE to convey PE receive defects, when
CCM transmission is enabled.  
[Lizhong] "PE receive defects" refer to PE AC receive defects or both AC and PE receive defects?

4.2. Use of PW Status notification for MPLS PSNs  

There are also scenarios where a PE carries out PW label withdrawal
instead of PW status notification. These include administrative
disablement of the PW or loss of Target LDP session with the peer
PE.
[Lizhong] There is another PW/AC status signaling method by using label withdraw method when PW status notification is not supported. Is it intentionally ignored?

4.3. Use of BFD Diagnostic Codes

When using VCCV, the control channel (CC) type and Connectivity
Verification (CV) Type are agreed on between the peer PEs using the
OAM capability sub-TLV signaled as part of the interface parameter
TLV when using FEC 129 and the interface parameter sub-TLV when
using FEC 128.  
[Lizhong] the "OAM capability sub-TLV" refer to "VCCV interface parameters sub-TLV", right? Suggest to align with terminology in RFC5085.

5. Ethernet AC Defect States Entry or Exit Criteria
[Lizhong] context of AC receive/transmit defect entry is duplicated with that in section 2.2. Is it possible to make the context more simple, either in section 2.2 or 5.1?

6. Ethernet AC and PW Defect States Interworking
[Lizhong] RFC2119 words should be used in this section, e.g, "must" should be "MUST".

6.1. PW Receive Defect Entry Procedures
[Lizhong] this section does not describe the mechanism to enter PW receive defect state, is it same with that in section 2.2?

Further, when PE1 enters the Receive Defect state, it must assume
that PE2 has no knowledge of the defect and must send reverse
defect failure notification to PE2. For MPLS PSN or MPLS-IP PSN,
this is done via either a PW Status notification message indicating
a reverse defect; or via VCCV-BFD diagnostic code of reverse defect
if VCCV CV type of 0x08 had been negotiated.
[Lizhong] why CV type of 0x20 is missed here?

6.2. PW Receive Defect Exit Procedures
[Lizhong] this section does not describe the mechanism to exit PW receive defect state?

If PW receive defect was established via notification from PE2 or
via loss of control adjacency, no additional action is needed,
since PE2 is expected to be aware of the defect clearing.
[Lizhong] the above description is incorrect in this section. The exit of PW receive defect should be described, not enter of PW receive defect.

6.3. PW Transmit Defect Entry Procedures

- If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is
used for fault notification, PE1 must transmit E-LMI asynchronous
STATUS message with report type Single EVC Asynchronous Status
indicating that PW is Not Active.
[Lizhong] shouldn't the entry of PW transmit defect be signaled to remote PE? I do not see such text here.

6.4. PW Transmit Defect Exit Procedures

- If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must
transmit E-LMI asynchronous STATUS message with report type Single
EVC Asynchronous Status indicating that PW is Active.
[Lizhong] same comment as for previous section, shouldn't the exit of PW transmit defect be signaled to remote PE? I do not see such text here.

6.5. AC Receive Defect Entry Procedures

When Native Service OAM mechanism is supported on PE1, it can also
use the NS OAM notification as specified in Section 4.1.  
[Lizhong] is there any relationship between notification mechanism in CE domain and mechanism in PE domain. I mean if the AC uses NS OAM to detect defect in CE domain, does NS OAM between PEs have any priority to apply?

Nits:
There are some nits that need to resolve. Please check link: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt

Regards
Lizhong --=_alternative 004A90D948257A5A_=-- From manav.bhatia@alcatel-lucent.com Wed Aug 15 05:41:04 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 8975821F8807 for ; Wed, 15 Aug 2012 05:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.742 X-Spam-Level: X-Spam-Status: No, score=-7.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txJKmbGTVBou for ; Wed, 15 Aug 2012 05:41:03 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD0721F8806 for ; Wed, 15 Aug 2012 05:41:03 -0700 (PDT) Received: from ihemail2.lucent.com (h135-245-2-35.lucent.com [135.245.2.35]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7FCf2nb029976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 07:41:02 -0500 (CDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q7FCewwa002707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 07:41:01 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7FCevwO001102 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 Aug 2012 18:10:58 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 15 Aug 2012 18:10:57 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-ads@tools.ietf.org" Date: Wed, 15 Aug 2012 18:09:38 +0530 Thread-Topic: RtgDir review: draft-ietf-armd-problem-statement-03 Thread-Index: Ac164wjUJdJmNCDFQXqpVYzDnTP0Nw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D063A0AF5@INBANSXCHMBSA1.in.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "rtg-dir@ietf.org" , "draft-ietf-armd-problem-statement.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-armd-problem-statement-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 12:41:04 -0000 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-armd-problem-statement-03 Reviewer: Manav Bhatia Review Date: Aug 15 2012 IETF LC End Date: Aug 23 2012 Intended Status: Informational =20 Summary: I have some concerns about this document that I think should be re= solved before publication. Major Issues: 1. In Sec 5 why is there a "may" in the following statement? "From an L2 perspective, sending to a multicast vs. broadcast address *may*= result in the packet being delivered to all nodes, but most (if not all) n= odes will filter out the (unwanted) query via filters installed in the NIC = -- hosts will never see such packets. " "may" seems to indicate that there are scenarios when a multicast from an L= 2 perspective will not be delivered to all nodes. I am unable to envisage a= scenario when this can happen? All BUM (broadcast, unlearnt unicast and mu= lticast) traffic in vanilla L2 and VPLS (Virtual Private Lan Service) is de= livered to *all* nodes. There are exceptions in H-VPLS or if MMRP is enable= d but I suspect if the authors had this in their mind when they wrote the a= bove text. 2. Sec 7.1 begins with the following text: "One pain point with large L2 broadcast domains is that the routers connect= ed to the L2 domain need to process "a lot of" ARP traffic." I am not sure if this is correct with how an L2 broadcast domain has been d= efined in Sec 2. I would wager that a bigger pain point for a large L2 broa= dcast domain would be handling unknown unicast traffic that needs to get fl= ooded, instead of dealing with the "ARP" traffic. I am aware of very very l= arge L2 broadcast domains that have no ARP/ND scaling problems. Would it th= en make more sense to replace the L2 broadcast domain with an ARP/ND domain= ? If Yes, then ARP/ND domain too needs to be defined in Sec 2. 3. Sec 7.1 seems to suggest that Gratuitous ARPs pre-populate ARP caches on= the neighboring devices. Without an explicit description of what a neighbo= ring device is, I would presume that this also includes edge/core routers. = In that case this statement is not entirely correct as I am aware of router= s that will by default not pre-populate their ARP caches on receiving Gratu= itous ARPs. 4. Sec 7.2 must also discuss the scaling impact of how the neighbor cache i= s maintained in IPv6 - especially the impact of moving the neighbor state f= rom REACHABLE to STALE. Once the "IPv6 ARP" gets resolved the neighbor entr= y moves from the REACHABLE to STALE after around 30secs. The neighbor entry= remains in this state till a packet needs to be forwarded to this neighbor= . The first time a node sends a packet to a neighbor whose entry is STALE, = the sender changes the state to DELAY and sets a timer to expire in around = 5 seconds. Most routers initiate moving the state from STALE to DELAY by pu= nting a copy of the data packet to CPU so that the sender can reinitiate th= e Neighbor discovery process. This patently can be quite CPU and buffer int= ensive if the neighbor cache size is huge. Minor Issues: 1. Sec 2 - Terminology should define Address Resolution as this seems to be= the core issue that the draft is discussing. Address Resolution: Address resolution is the process through which a node= determines the link-layer address of a neighbor given only its IP address.= In IPv6, address resolution is performed as part of Neighbor Discovery [R= FC4861], Section 7.2. 2. In Sec 7.1 you mention that routers need to drop all transit traffic whe= n there is no response received for an ARP/ND request. You should mention t= hat in addition to this, routers also need to send an ICMP host unreachable= error packet back to the sender. ICMP error packets are generated in the c= ontrol card CPU. So, if the CPU has to generate a high number of such ICMP = errors then this can load the CPU. The whole process can be quite CPU as we= ll as buffer intensive. The CPU/buffer overload is usually mitigated by rat= e limiting the number of ICMP errors generated. 3. In Sec 7.1 you mention that the entire ARP/ND process can be quite CPU i= ntensive since transit data traffic needs to be queued while the address re= solution is underway. You could mention that this is mitigated by offloadin= g the queuing part to the line card CPUs so that the CPU on the control car= d is not inundated with such packets. This obviously would only work on dis= tributed systems that have separate CPUs on the line cards and the main car= d. 4. Sec 7.1 should mention that this could be used as a DoS attack wherein t= he attacker sends a high volume of packets for which ARPs need to be resolv= ed. This could result in genuine packets that need to resolve ARPs getting = dropped as there is only a finite rate at which packets are sent to CPU for= ARP resolution. Again this is both CPU and buffer intensive. 5. Sec 7.2 discusses issues with address resolution mechanism in IPv6. I th= ink its useful for this draft to discuss the fact that unlike IPv4, IPv6 ha= s subnets that are /64. This number is quite large and will perhaps cover t= rillions of IP addresses, most of which would be unassigned. Thus simplisti= c IPv6 ND implementations can be vulnerable to attacks which inundates the = CPU with huge requests to perform address resolution for a large number of = IPv6 addresses, most of which are unassigned. As a result of this genuine I= Pv6 devices will not be able to join the network. You might want to refer t= o RFC 6583 for more details. 6. The last paragraph of Sec 7.3 says the following: "Finally, IPv6 and IPv4 are often run simultaneously and in parallel on the= same network, i.e., in dual-stack mode. In such environments, the IPv4 an= d IPv6 issues enumerated above compound each other." While I understand the sentiment behind the above statement, I fail to see = how this is related to the MAC problem being described in Sec 7.3. The MAC = scaling is a function of the total number of unique MACs that the system ha= s to learn and is orthogonal to the presence of IPv4 or IPv6. I read this s= tatement to mean that something extra happens in the dual stack mode which = exacerbates the MAC problem even further. This I believe is patently not th= e case. 7. Sec 11 - Security Considerations should at the very least give pointers = to references on issues related to ARP security vulnerabilities. I don't se= e IPv6 ND mentioned at all. Since ND relies on ICMPv6 and does not run dire= ctly over layer 2, there could possibly be security concerns specific to ND= in the data center environments that don't apply to ARP. This document oug= ht to discuss those so that ARMD (or some other WG) can look at solutions a= ddressing those concerns.=20 8. Should it be mentioned in the document somewhere (sec 11?) that data cen= ter administrators can configure ACLs to filter packets addressed to unallo= cated IPv6 addresses? Folks can consider the valid IPv6 address ranges and = filter out packets that use the unallocated addresses. Doing this will avoi= d unnecessary ARP resolution for invalid IPv6 addresses. The list of the IP= v6 addresses that are legitimate and should be permitted is small and maint= ainable because of IPv6's address hierarchy. http://www.iana.org/assignment= s/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml giv= es a list of large address blocks that have been allocated by IANA. Cheers, Manav= From acee.lindem@ericsson.com Fri Aug 17 05:38: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 7A05021F8517; Fri, 17 Aug 2012 05:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 XSV-EmdpCgUH; Fri, 17 Aug 2012 05:38:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E4CAC21F847D; Fri, 17 Aug 2012 05:38:49 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7HCdHcX008074; Fri, 17 Aug 2012 07:39:20 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.190]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 17 Aug 2012 08:38:39 -0400 From: Acee Lindem To: Ted Lemon Date: Fri, 17 Aug 2012 08:38:37 -0400 Thread-Topic: [RTG-DIR] DHCPv6 Prefix Pool Option Thread-Index: Ac18dTlosVjgMFX8TvGBHSS6Kcn3QA== Message-ID: <8E54F935-4870-44DC-B048-6267A41FECEE@ericsson.com> References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> <3E00A188-D7F9-44AD-A9A7-DF49BE6484AF@fugue.com> <6C2CDBAF-3F66-4B83-8697-2B073967B166@fugue.com> In-Reply-To: <6C2CDBAF-3F66-4B83-8697-2B073967B166@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-10--319786046"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Leaf yeh , "rtg-dir@ietf.org" , "dhc-chairs@tools.ietf.org Chairs" , "" , "routing-discussion@ietf.org" Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 17 Aug 2012 12:38:50 -0000 --Apple-Mail-10--319786046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ted,=20 I've been on vacation. I guess I see this as a case of the tail wagging = the dog with the BNG getting routing aggregation policy from the DHCPv6 = server. However, I'm certainly not going to let my opinion as a routing = chair and developer of a leading BNG platform hold up the will of an = entire working group. The "Security Considerations" section does need = to be beefed up as this does increase the exposure - just imagine a = subverted DHCPv6 responding with 0::/0. Thanks, Acee=20 On Aug 10, 2012, at 8:50 AM, Ted Lemon wrote: > So, I haven't heard any discussion on this topic since I wrote a = clarifying message on August 6 about the intended use case for this = option. Does this mean that we've satisfactorily addressed the use = case question that Acee raised, and that no-one else objects, or does it = mean that everybody is taking a well-deserved break from IETF email = following the Vancouver meeting? >=20 --Apple-Mail-10--319786046 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgxNzEyMzgzOFowIwYJKoZI hvcNAQkEMRYEFKH4AHOSrEOohRng50IZyFdCuSVDMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgCjwiSMIV33rfsHSoprYExfLiEELsFRhRmzXWoSua5OoyKlJQoOd31Z+cw2O6XNL hTmCAvm+CNQkgwWeQAIZpEFgil7EDGSJo4pLslkKLrgjSOw+mhfy3Na18/DPR/N9s6VGHdNfaEB9 AxyKoo6U4VuSwEg8pVdaraIGpG37Ehz2AAAAAAAA --Apple-Mail-10--319786046-- From hadi@mojatatu.com Sat Aug 18 05:55: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 A210421F8549 for ; Sat, 18 Aug 2012 05:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqvZ3jAuztnT for ; Sat, 18 Aug 2012 05:55:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 143D421F8541 for ; Sat, 18 Aug 2012 05:55:01 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7772751obb.31 for ; Sat, 18 Aug 2012 05:55:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=ZMx0nxptIGfUlOl2ZkyKD2q6g5my/TQzoOTJFoaq9qw=; b=FTKFkKT4APCMr9lm4YoWWfqsAy8V83/MkfWPE7gyxPiFvS+e4WJJgCEkbmLeLYM19e lalqasPE7As1NXuIUaaHxjI4axkhlw2qVR9MRDGfO1Xg76A7MSM6UQj3Gh7eVyD8RVxR UFTTetfYuKBkvy3hsDiOuU6WCvOEsFQqNkFe/d7e08WMzoIxGDMPECKmmCxvaaVwxmN/ MwKKYjn72coxGMGMKrB/kStl+r9IB3NPT9rxGOa5I69lPqj98tq+U9kwJFPpdyN3pRk4 KI3QhaQZ1KT+99AH/w6WXskBxXY5z97CLvDWnw9OS/gcUaPp4U3Wh71jPEwaeZcrL1vW qIhA== Received: by 10.182.169.37 with SMTP id ab5mr6181025obc.82.1345294501619; Sat, 18 Aug 2012 05:55:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.79.194 with HTTP; Sat, 18 Aug 2012 05:54:41 -0700 (PDT) From: Jamal Hadi Salim Date: Sat, 18 Aug 2012 08:54:41 -0400 Message-ID: To: "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" , pce-chairs@tools.ietf.org, draft-ietf-pce-hierarchy-fwk@tools.ietf.org, julien.meuric@orange.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn3Doj5EwfZ9c8PcGTiW/sOHv25Cx6PI5MkB0x2YnB2xQeJ4CcVCTcZSHYUmEmQTgPsZ0MN Subject: [RTG-DIR] RtgDir review: draft-ietf-pce-hierarchy-fwk-04.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: Sat, 18 Aug 2012 12:55:02 -0000 Hi, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, 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-pce-hierarchy-fwk-04.txt Reviewer: Jamal Hadi Salim Review Date: 2012-08-18 IETF LC End Date: 2012-08-24 Intended Status: Informational Summary: This document is basically ready for publication, but has minor but important readability nits that should be considered prior to publication. Comments: The document describes how the PCE architecture can be extended through the use of hierarchical relationship between domains to compute an optimum path over a sequence of domains. The draft is well written with good clarity on the purpose and functionality of the intended messages. Major Issues: None Minor Issues: None Nits: 1) The term "antonymous" appears 5 times it almost made me believe it was intended. I think that should be "autonomous". 2) Section 1.3.1 "See Section 5.1" should be "See Section 4.1" 3) Section 1.3.2.1 "Within a Carrier's Carrier ..." should be: "Within a Carrier's carrier .." i.e second carrier is all lower-case 4) Section 2.2. Unnecessary empty line after: "from its entry BNs to its exit BNs that connect to the rest of the" 5) Section 4.6.2 i) "described in Section 5.6.1" should be: "described in Section 4.6.1" ii) "(See Section 5.5)" should be: "(See Section 4.5)" 6) Section 4.7 ".. path to the egress. The child PCE should return the relevant .." should be: ".. path to the egress, the child PCE should return the relevant .." cheers, jamal From leaf.y.yeh@huawei.com Wed Aug 22 03:49:20 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 0399921F846F; Wed, 22 Aug 2012 03:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 ARBGChuei3zc; Wed, 22 Aug 2012 03:49:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F117121F86C6; Wed, 22 Aug 2012 03:48:47 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJU11563; Wed, 22 Aug 2012 02:48:47 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 03:44:49 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 03:44:48 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Wed, 22 Aug 2012 18:44:45 +0800 From: Leaf yeh To: Acee Lindem , Ted Lemon Thread-Topic: [RTG-DIR] DHCPv6 Prefix Pool Option Thread-Index: AQHNc9dJ9dYDWKvg6U6z8H0vqwSvwpdOLNGwgARS2ACACvz9gIAHsclA Date: Wed, 22 Aug 2012 10:44:45 +0000 Message-ID: References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> <3E00A188-D7F9-44AD-A9A7-DF49BE6484AF@fugue.com> <6C2CDBAF-3F66-4B83-8697-2B073967B166@fugue.com> <8E54F935-4870-44DC-B048-6267A41FECEE@ericsson.com> In-Reply-To: <8E54F935-4870-44DC-B048-6267A41FECEE@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 22 Aug 2012 04:01:23 -0700 Cc: "rtg-dir@ietf.org" , "dhc-chairs@tools.ietf.org Chairs" , "" , "routing-discussion@ietf.org" Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 22 Aug 2012 10:49:20 -0000 Acee - The "Security Considerations" section does need to be beefed up as = this does increase the exposure - just imagine a subverted DHCPv6 respondin= g with 0::/0. I believe draft (OPTION_PREFIX_POOL) will have the same "security considera= tions" as that for the mechanism of DHCPv6-PD (OPTION_IA_PD), when BNG acts= as the DHCPv6 relay for DHCPv6-PD. DHCPv6-PD (OPTION_IA_PD) does also have the exposure on the routing for the= customer network. While OPTION_PREFIX_POOL sets up the aggregation route, = OPTION_IA_PD also request to set up route for the customer network on the P= E router. If the subverted PD prefix is ::/0, then the PE router will face the same p= roblem, right? I suppose the DHCPv6 server, acting as the role of network administrator, n= eeds to prevent this case happen. Best Regards, Leaf -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Friday, August 17, 2012 8:39 PM To: Ted Lemon Cc: routing-discussion@ietf.org; rtg-dir@ietf.org; dhc-chairs@tools.ietf.or= g Chairs; ; Leaf yeh Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option Hi Ted,=20 I've been on vacation. I guess I see this as a case of the tail wagging the= dog with the BNG getting routing aggregation policy from the DHCPv6 server= . However, I'm certainly not going to let my opinion as a routing chair and= developer of a leading BNG platform hold up the will of an entire working = group. The "Security Considerations" section does need to be beefed up as = this does increase the exposure - just imagine a subverted DHCPv6 respondin= g with 0::/0. Thanks, Acee=20 On Aug 10, 2012, at 8:50 AM, Ted Lemon wrote: > So, I haven't heard any discussion on this topic since I wrote a clarifyi= ng message on August 6 about the intended use case for this option. Does = this mean that we've satisfactorily addressed the use case question that Ac= ee raised, and that no-one else objects, or does it mean that everybody is = taking a well-deserved break from IETF email following the Vancouver meetin= g? >=20 From acee.lindem@ericsson.com Wed Aug 22 12:49: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 B2DEE21F86B0; Wed, 22 Aug 2012 12:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 dSX-vzCUi-Sl; Wed, 22 Aug 2012 12:49:10 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DED8D21F85BB; Wed, 22 Aug 2012 12:49:09 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7MJoAdH011063; Wed, 22 Aug 2012 14:50:14 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.166]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 22 Aug 2012 15:48:54 -0400 From: Acee Lindem Date: Wed, 22 Aug 2012 15:48:51 -0400 Thread-Topic: [RTG-DIR] DHCPv6 Prefix Pool Option Thread-Index: Ac2AnykG3UMO6SGMQGOe63/SawbdcA== Message-ID: <4F7049DC-C8ED-40F9-8ECD-DF030B8DFF31@ericsson.com> References: <019101cd70e5$c949c890$5bdd59b0$@olddog.co.uk> <3C8E8056-D034-453E-98F6-A028DE304286@ericsson.com> <3E00A188-D7F9-44AD-A9A7-DF49BE6484AF@fugue.com> <6C2CDBAF-3F66-4B83-8697-2B073967B166@fugue.com> <8E54F935-4870-44DC-B048-6267A41FECEE@ericsson.com> In-Reply-To: <8E54F935-4870-44DC-B048-6267A41FECEE@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-16-138028279"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "routing-discussion@ietf.org" , Ted Lemon , "dhc-chairs@tools.ietf.org Chairs" , "" , Leaf yeh Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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, 22 Aug 2012 19:49:10 -0000 --Apple-Mail-16-138028279 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Leaf, On Aug 17, 2012, at 8:38 AM, Acee Lindem wrote: > Hi Ted,=20 > I've been on vacation. I guess I see this as a case of the tail = wagging the dog with the BNG getting routing aggregation policy from the = DHCPv6 server. However, I'm certainly not going to let my opinion as a = routing chair and developer of a leading BNG platform hold up the will = of an entire working group. The "Security Considerations" section does = need to be beefed up as this does increase the exposure - just imagine a = subverted DHCPv6 responding with 0::/0. There is discussion of this case in RFC 3633 "Security Considerations". = However, I'd now expect the mechanisms to authenticate the DHCP = exchanges to be more mature. Also, the threats of readvertisement need = to be discussed better than in RFC 3633.=20 Thanks, Acee=20 > Thanks, > Acee=20 > On Aug 10, 2012, at 8:50 AM, Ted Lemon wrote: >=20 >> So, I haven't heard any discussion on this topic since I wrote a = clarifying message on August 6 about the intended use case for this = option. Does this mean that we've satisfactorily addressed the use = case question that Acee raised, and that no-one else objects, or does it = mean that everybody is taking a well-deserved break from IETF email = following the Vancouver meeting? >>=20 >=20 --Apple-Mail-16-138028279 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 SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgyMjE5NDg1MlowIwYJKoZI hvcNAQkEMRYEFFpm4gqTqvnSDaHw1kJIyZu7sD27MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgI7AZ8GDUIVMukqR1yHazAysMmlbxUrNtjelaooe8aDR6NU8eT9TLLCxm8K1ClQk lZnudl3pYyuIeHMBN/Nmmze9lAuLi+eBaMiupodQhniLgtV0RqQJBQqP47XhPMvNv2Imb6fA0YBf WHufSQFOyBOKtVP8fHtN0CJWXpRrGDbcAAAAAAAA --Apple-Mail-16-138028279-- From manav.bhatia@alcatel-lucent.com Tue Aug 28 01:25: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 2D13F11E80DE; Tue, 28 Aug 2012 01:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.349 X-Spam-Level: X-Spam-Status: No, score=-9.349 tagged_above=-999 required=5 tests=[AWL=1.250, 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 NBIb85gHjatM; Tue, 28 Aug 2012 01:25:15 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C0D4D11E80A3; Tue, 28 Aug 2012 01:25:15 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q7S8PBwW019574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Aug 2012 03:25:14 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7S8P9Gl002910 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Aug 2012 13:55:10 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 28 Aug 2012 13:55:08 +0530 From: "Bhatia, Manav (Manav)" To: Thomas Narten Date: Tue, 28 Aug 2012 13:50:59 +0530 Thread-Topic: RtgDir review: draft-ietf-armd-problem-statement-03 Thread-Index: Ac2Emn+J32bcE+5qQJSlycTwjNR6KgAOZYow Message-ID: <7C362EEF9C7896468B36C9B79200D8350D06450BB6@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D063A0AF5@INBANSXCHMBSA1.in.alcatel-lucent.com> <201208272124.q7RLOnx7015943@cichlid.raleigh.ibm.com> In-Reply-To: <201208272124.q7RLOnx7015943@cichlid.raleigh.ibm.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "rtg-dir@ietf.org" , "armd@ietf.org" , "draft-ietf-armd-problem-statement.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-armd-problem-statement-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 08:25:17 -0000 Hi Thomas, [clipped] =20 > This is poorly worded. How about I replace the paragraph with the > following: >=20 > Broadly speaking, from the perspective of address resolution, > IPv6's Neighbor Discovery (ND) behaves much like ARP, with a > few notable differences. First, ARP uses broadcast, whereas ND > uses multicast. Specifically, when querying for a target IP > address, ND maps the target address into an IPv6 Solicited > Node multicast address. Using multicast rather than broadcast > has the benefit that the multicast frames do not necessarily > need to be sent to all parts of the network, i.e., only to > segments where listeners for the Solicited Node multicast > address reside. In the case where multicast frames are > delivered to all parts of the network, sending to a multicast > still has the advantage that most (if not all) nodes will > filter out the (unwanted) multicast query via filters > installed in the NIC rather than burdening host software with > the need to process such packets. Thus, whereas all nodes must > process every ARP query, ND queries are processed only by the > nodes to which they are intended. In cases where multicast > filtering can't effectively be implemented in the NIC (e.g., > as on hypervisors supporting virtualization), filtering would > need to be done in software (e.g., in the hypervisor's > vSwitch). >=20 > > "may" seems to indicate that there are scenarios when a multicast > > from an L2 perspective will not be delivered to all nodes. >=20 > Correct. >=20 > > I am unable to envisage a scenario when this can happen? All BUM > > (broadcast, unlearnt unicast and multicast) traffic in vanilla L2 > > and VPLS (Virtual Private Lan Service) is delivered to *all* > > nodes. There are exceptions in H-VPLS or if MMRP is enabled but I > > suspect if the authors had this in their mind when they wrote the > > above text. >=20 > Hopefully the proposed text answers the above questions. Thanks, the proposed text is much better. However, the draft still says "multicast frames do not necessarily need to = be sent to all parts of the network". I could be missing something but ther= e still seems to be some disconnect because in the context of L2, multicast= frames will be sent to all parts of the network.=20 >=20 > > 2. Sec 7.1 begins with the following text: >=20 > > "One pain point with large L2 broadcast domains is that the routers > > connected to the L2 domain need to process "a lot of" ARP traffic." >=20 > > I am not sure if this is correct with how an L2 broadcast domain has > > been defined in Sec 2. I would wager that a bigger pain point for a > > large L2 broadcast domain would be handling unknown unicast traffic > > that needs to get flooded, instead of dealing with the "ARP" > > traffic. I am aware of very very large L2 broadcast domains that > > have no ARP/ND scaling problems. Would it then make more sense to > > replace the L2 broadcast domain with an ARP/ND domain? If Yes, then > > ARP/ND domain too needs to be defined in Sec 2. >=20 > The issue (as has been discussed in ARMD) is specifically the ARP > processing load (and not unknown unicast traffic). In typical > implementations, ARP processing is done by a service processor with > limited capacity. The cited problem is that the amount of ARP traffic > places a significant load on that processor. >=20 > This is explained in the next pargraph. How about I add the following > sentence to the 2nd paragraph.: >=20 > In some deployments, limitations on the rate of ARP processing > have been cited as being a problem. >=20 > Does that work? Yes it does as long as you remove the original line that I had quoted. >=20 > > 3. Sec 7.1 seems to suggest that Gratuitous ARPs pre-populate ARP > > caches on the neighboring devices. Without an explicit description > > of what a neighboring device is, I would presume that this also > > includes edge/core routers. In that case this statement is not > > entirely correct as I am aware of routers that will by default not > > pre-populate their ARP caches on receiving Gratuitous ARPs. >=20 > Right. The spec says "don't do this". But I believe it was asserted > that some implementations do this. That said, I'm not aware of any > such implementations. I would be willing to remove this sentence in > the absence of known implementations of this. This clearly is not the default behavior for several core/edge router imple= mentations that I am aware of. So at best there could be a subset of router= s that do this. In which case you need to fix the text that claims that *al= l* routers pre-populate ARP caches upon receiving Gratuitous ARPs. >=20 > > 4. Sec 7.2 must also discuss the scaling impact of how the neighbor > > cache is maintained in IPv6 - especially the impact of moving the > > neighbor state from REACHABLE to STALE. Once the "IPv6 ARP" gets > > resolved the neighbor entry moves from the REACHABLE to STALE after > > around 30secs. The neighbor entry remains in this state till a > > packet needs to be forwarded to this neighbor. The first time a > > node sends a packet to a neighbor whose entry is STALE, the sender > > changes the state to DELAY and sets a timer to expire in around 5 > > seconds. Most routers initiate moving the state from STALE to DELAY > > by punting a copy of the data packet to CPU so that the sender can > > reinitiate the Neighbor discovery process. This patently can be > > quite CPU and buffer intensive if the neighbor cache size is huge. >=20 > This could be. But the WG did not report such specific details in > terms of actual problems reported from deployments. >=20 > Care to say more about what these "most implementations" are and how > common they are? And are they the *only* way to implement this > feature, or have other vendors chosen different implementations > without this limitation? >=20 > That said, I could add the following to the document: >=20 > Routers implementing NUD (for neighboring destinations) will > need to process neighbor cache state changes such as > transitioning entries from REACHABLE to STALE. How this > capability is implemented may impact the scalabability of ND > on a router. For example, one possible implementation is to > have the forwarding operation detect when an ND entry is > referenced that needs to transition from REACHABLE to STALE, > by signalling an event that would need to be processed by the > software processor. Such an implementation could increase the > load on the service processor much in the same way that a high > rate of ARP requests have led to problems on some routers. Looks good. [clipped] >=20 >=20 > > 2. In Sec 7.1 you mention that routers need to drop all transit > > traffic when there is no response received for an ARP/ND > > request. You should mention that in addition to this, routers also > > need to send an ICMP host unreachable error packet back to the > > sender. ICMP error packets are generated in the control card > > CPU. So, if the CPU has to generate a high number of such ICMP > > errors then this can load the CPU. The whole process can be quite > > CPU as well as buffer intensive. The CPU/buffer overload is usually > > mitigated by rate limiting the number of ICMP errors generated. >=20 > Added: >=20 > "and may send an ICMP destination unreachable message as well." Why a "may"? An implementation is violating a standard if it isn't. >=20 > > 3. In Sec 7.1 you mention that the entire ARP/ND process can be > > quite CPU intensive since transit data traffic needs to be queued > > while the address resolution is underway. You could mention that > > this is mitigated by offloading the queuing part to the line card > > CPUs so that the CPU on the control card is not inundated with such > > packets. This obviously would only work on distributed systems that > > have separate CPUs on the line cards and the main card. >=20 > There are many things one could say about ARP implementations. But > that is not the purpose of this document. It is really about outlining > the problems... So I think the above is getting too detailed. >=20 > > 4. Sec 7.1 should mention that this could be used as a DoS attack > > wherein the attacker sends a high volume of packets for which ARPs > > need to be resolved. This could result in genuine packets that need > > to resolve ARPs getting dropped as there is only a finite rate at > > which packets are sent to CPU for ARP resolution. Again this is > > both CPU and buffer intensive. >=20 > Again, I don't think this document needs to cover all aspects of ND. >=20 > > 5. Sec 7.2 discusses issues with address resolution mechanism in > > IPv6. I think its useful for this draft to discuss the fact that > > unlike IPv4, IPv6 has subnets that are /64. This number is quite > > large and will perhaps cover trillions of IP addresses, most of > > which would be unassigned. Thus simplistic IPv6 ND implementations > > can be vulnerable to attacks which inundates the CPU with huge > > requests to perform address resolution for a large number of IPv6 > > addresses, most of which are unassigned. As a result of this > > genuine IPv6 devices will not be able to join the network. You > > might want to refer to RFC 6583 for more details. >=20 > Ditto. I am fine with your resolution to the comments 3 and 4. However, I believe = that 5 ought to be discussed. This document is about ARP/ND issues that fol= ks are either seeing or will see in large data centers. Given this, I don't= see why this should not even be discussed in this draft. I think its quite= reasonable to address the above mentioned aspect of IPv6 ND and one of way= getting attention to issue is by discussing this here in this draft. >=20 > > 7. Sec 11 - Security Considerations should at the very least give > > pointers to references on issues related to ARP security > > vulnerabilities. I don't see IPv6 ND mentioned at all. Since ND > > relies on ICMPv6 and does not run directly over layer 2, there > > could possibly be security concerns specific to ND in the data > > center environments that don't apply to ARP. This document ought to > > discuss those so that ARMD (or some other WG) can look at solutions > > addressing those concerns. >=20 > Actually, I disagree somewhat. This document doesn't need to get into > all the security issues of ARP and/or ND. For one thing, they did not > come up as "problems" in ARMD. :-) I will put in pointers to the ND > security considerations section. How about I add the following > sentence: >=20 > Security considerations for Neighbor Discovery are discussed in > and = . This should be good. I assume that this then means that there are no additi= onal security concerns with ARPs/ND in data centers. Can you also remove the first line from the Security Consideration? Its red= undant and has already been said earlier. >=20 > > 8. Should it be mentioned in the document somewhere (sec 11?) that > > data center administrators can configure ACLs to filter packets > > addressed to unallocated IPv6 addresses? Folks can consider the > > valid IPv6 address ranges and filter out packets that use the > > unallocated addresses. Doing this will avoid unnecessary ARP > > resolution for invalid IPv6 addresses. The list of the IPv6 > > addresses that are legitimate and should be permitted is small and > > maintainable because of IPv6's address > > hierarchy. http://www.iana.org/assignments/ipv6-unicast-address- > assignments/ipv6-unicast-address-assignments.xml > > gives a list of large address blocks that have been allocated by > > IANA. >=20 > IMO no. This goes beyond the scope of this document. While I don't see any harm in mentioning this, I leave it on you/WG to deci= de if you want to include this or not. I just noticed that Sec 8 - Summary, is redundant. Shouldnt that entire tex= t be moved to either the Abstract or the Introduction? Cheers, Manav From abdussalambaryun@gmail.com Sun Aug 26 05:42: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 3534621F8497; Sun, 26 Aug 2012 05:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 lDw+U-HlpMH1; Sun, 26 Aug 2012 05:42:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 476E021F8491; Sun, 26 Aug 2012 05:42:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3915820vbb.31 for ; Sun, 26 Aug 2012 05:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mppgc9FjmnT92Gq27lQKNKTpqxiBxlaqmwKMrlCivaI=; b=qUy7k0x8tQNr3fd4T2R2/HMyI9D29hYKUY/7ol0Lw6HoTL8gZGaZoCiF5GakZ7MExg eLfqab08U2DYQkUU4wlQ+jessEZUeefVraHTeZgo0utdnsuka98/s8TipdDXCJM8wF6d 4pjYBQu9VU4g4b6pXJ3DknIZmOGgV8StBBluQ4S/j5UON60PfyvAsenMOXdJ6WfPeNE8 MAB7Bl8mONIGCjB6YWHFQ2Vk/w8XxsuYCTK2pKf94vyAWd8TVo7NAbrFvUki17UYv0ja B+gV4bYfDOUfnU5ID7V6RdBl8h6Fd/CGTrO+e5FiDk/5/J+Z31CBeNs5VGqjw7Hlv381 3jrQ== MIME-Version: 1.0 Received: by 10.58.32.233 with SMTP id m9mr10075512vei.23.1345984933668; Sun, 26 Aug 2012 05:42:13 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Sun, 26 Aug 2012 05:42:13 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Aug 2012 14:42:13 +0200 Message-ID: From: Abdussalam Baryun To: akatlas@juniper.net, tnadeau@juniper.net Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 28 Aug 2012 04:52:12 -0700 Cc: rtg-dir@ietf.org, routing-discussion@ietf.org Subject: Re: [RTG-DIR] Discussion of "Interface to the Routing System" in Vancouver X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 12:42:15 -0000 Hi Alia and Dave, Reading through to find the definition of IRS within it still is not clear for me, not sure its relationship with the network interfaces, please advise, Regards AB === > Hi, > > We have a slot on the agenda of the Routing Area Open Meeting to discuss a > proposal for new work on an "Interface to the Routing System". We want to > spend > a little time looking at the proposal to see whether it has legs and to > gauge > the interest. In summary, the idea is to standardise a programmatic > interface > for full-duplex, streaming state transfer in and out of the Internet's > routing > system. > > You can read an I-D on the subject at > http://lucidvision.com/draft-ward-irs-framework-00.txt (this will be posted > on > Monday when the gates re-open) and there will be slides to guide the > dicussion. > > I will also be opening a non-WG mailing list to give a place to discuss > this > topic. > > Adrian > From tnadeau@juniper.net Mon Aug 27 10:24:09 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 1804F21F856D; Mon, 27 Aug 2012 10:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 lAtXYhQHY7tc; Mon, 27 Aug 2012 10:24:08 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 2228D21F8440; Mon, 27 Aug 2012 10:24:08 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUDutMat7CESHYWqDfRVXMAYXMVG5hcM8@postini.com; Mon, 27 Aug 2012 10:24:08 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Aug 2012 10:21:53 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 27 Aug 2012 10:21:52 -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; Mon, 27 Aug 2012 13:21:38 -0400 From: Thomas Nadeau To: Abdussalam Baryun , Alia Atlas Date: Mon, 27 Aug 2012 13:21:38 -0400 Thread-Topic: Discussion of "Interface to the Routing System" in Vancouver Thread-Index: Ac2EeGreR0hDfmg+S/CqpeyxrMbomg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 28 Aug 2012 04:52:12 -0700 Cc: "rtg-dir@ietf.org" , "routing-discussion@ietf.org" Subject: Re: [RTG-DIR] Discussion of "Interface to the Routing System" in Vancouver 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, 27 Aug 2012 17:24:09 -0000 >Hi Alia and Dave, > >Reading through to find the definition of IRS within > it still is not clear for me, not sure >its relationship with the network interfaces, please advise, I am not sure what your question exactly is. Network interfaces are used by the routing system for route computation and ultimately used as forwarding entities once routes are computed. In IRS they are treated the same way they are treated today. --Tom > >Regards >AB >=3D=3D=3D >> Hi, >> >> We have a slot on the agenda of the Routing Area Open Meeting to >>discuss a >> proposal for new work on an "Interface to the Routing System". We want >>to >> spend >> a little time looking at the proposal to see whether it has legs and to >> gauge >> the interest. In summary, the idea is to standardise a programmatic >> interface >> for full-duplex, streaming state transfer in and out of the Internet's >> routing >> system. >> >> You can read an I-D on the subject at >> http://lucidvision.com/draft-ward-irs-framework-00.txt (this will be >>posted >> on >> Monday when the gates re-open) and there will be slides to guide the >> dicussion. >> >> I will also be opening a non-WG mailing list to give a place to discuss >> this >> topic. >> >> Adrian >> From narten@us.ibm.com Mon Aug 27 14:25:23 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 74F8A21F8501 for ; Mon, 27 Aug 2012 14:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dAec-9hkSB70 for ; Mon, 27 Aug 2012 14:25:22 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE3F21F84F7 for ; Mon, 27 Aug 2012 14:25:22 -0700 (PDT) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 27 Aug 2012 15:25:21 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 27 Aug 2012 15:25:19 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 640283E40040; Mon, 27 Aug 2012 15:25:18 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7RLOsnd167520; Mon, 27 Aug 2012 15:24:57 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7RLOrfP001214; Mon, 27 Aug 2012 15:24:53 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.24.175]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q7RLOqG3001151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2012 15:24:52 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q7RLOnx7015943; Mon, 27 Aug 2012 17:24:49 -0400 Message-Id: <201208272124.q7RLOnx7015943@cichlid.raleigh.ibm.com> To: "Bhatia, Manav (Manav)" In-reply-to: <7C362EEF9C7896468B36C9B79200D8350D063A0AF5@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D063A0AF5@INBANSXCHMBSA1.in.alcatel-lucent.com> Comments: In-reply-to "Bhatia, Manav (Manav)" message dated "Wed, 15 Aug 2012 18:09:38 +0530." Date: Mon, 27 Aug 2012 17:24:48 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12082721-1780-0000-0000-000008C7172E X-IBM-ISS-SpamDetectors: X-IBM-ISS-DetailInfo: BY=3.00000293; HX=3.00000196; KW=3.00000007; PH=3.00000001; SC=3.00000007; SDB=6.00169038; UDB=6.00038311; UTC=2012-08-27 21:25:20 X-Mailman-Approved-At: Tue, 28 Aug 2012 04:52:12 -0700 Cc: "rtg-dir@ietf.org" , armd@ietf.org, "draft-ietf-armd-problem-statement.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-armd-problem-statement-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 21:25:23 -0000 Hi Manov. Thanks for the review comments. "Bhatia, Manav (Manav)" writes: > Summary: I have some concerns about this document that I think > should be resolved before publication. > Major Issues: > 1. In Sec 5 why is there a "may" in the following statement? > "From an L2 perspective, sending to a multicast vs. broadcast > address *may* result in the packet being delivered to all nodes, > but most (if not all) nodes will filter out the (unwanted) query > via filters installed in the NIC -- hosts will never see such > packets. " This is poorly worded. How about I replace the paragraph with the following: Broadly speaking, from the perspective of address resolution, IPv6's Neighbor Discovery (ND) behaves much like ARP, with a few notable differences. First, ARP uses broadcast, whereas ND uses multicast. Specifically, when querying for a target IP address, ND maps the target address into an IPv6 Solicited Node multicast address. Using multicast rather than broadcast has the benefit that the multicast frames do not necessarily need to be sent to all parts of the network, i.e., only to segments where listeners for the Solicited Node multicast address reside. In the case where multicast frames are delivered to all parts of the network, sending to a multicast still has the advantage that most (if not all) nodes will filter out the (unwanted) multicast query via filters installed in the NIC rather than burdening host software with the need to process such packets. Thus, whereas all nodes must process every ARP query, ND queries are processed only by the nodes to which they are intended. In cases where multicast filtering can't effectively be implemented in the NIC (e.g., as on hypervisors supporting virtualization), filtering would need to be done in software (e.g., in the hypervisor's vSwitch). > "may" seems to indicate that there are scenarios when a multicast > from an L2 perspective will not be delivered to all nodes. Correct. > I am unable to envisage a scenario when this can happen? All BUM > (broadcast, unlearnt unicast and multicast) traffic in vanilla L2 > and VPLS (Virtual Private Lan Service) is delivered to *all* > nodes. There are exceptions in H-VPLS or if MMRP is enabled but I > suspect if the authors had this in their mind when they wrote the > above text. Hopefully the proposed text answers the above questions. > 2. Sec 7.1 begins with the following text: > "One pain point with large L2 broadcast domains is that the routers > connected to the L2 domain need to process "a lot of" ARP traffic." > I am not sure if this is correct with how an L2 broadcast domain has > been defined in Sec 2. I would wager that a bigger pain point for a > large L2 broadcast domain would be handling unknown unicast traffic > that needs to get flooded, instead of dealing with the "ARP" > traffic. I am aware of very very large L2 broadcast domains that > have no ARP/ND scaling problems. Would it then make more sense to > replace the L2 broadcast domain with an ARP/ND domain? If Yes, then > ARP/ND domain too needs to be defined in Sec 2. The issue (as has been discussed in ARMD) is specifically the ARP processing load (and not unknown unicast traffic). In typical implementations, ARP processing is done by a service processor with limited capacity. The cited problem is that the amount of ARP traffic places a significant load on that processor. This is explained in the next pargraph. How about I add the following sentence to the 2nd paragraph.: In some deployments, limitations on the rate of ARP processing have been cited as being a problem. Does that work? > 3. Sec 7.1 seems to suggest that Gratuitous ARPs pre-populate ARP > caches on the neighboring devices. Without an explicit description > of what a neighboring device is, I would presume that this also > includes edge/core routers. In that case this statement is not > entirely correct as I am aware of routers that will by default not > pre-populate their ARP caches on receiving Gratuitous ARPs. Right. The spec says "don't do this". But I believe it was asserted that some implementations do this. That said, I'm not aware of any such implementations. I would be willing to remove this sentence in the absence of known implementations of this. > 4. Sec 7.2 must also discuss the scaling impact of how the neighbor > cache is maintained in IPv6 - especially the impact of moving the > neighbor state from REACHABLE to STALE. Once the "IPv6 ARP" gets > resolved the neighbor entry moves from the REACHABLE to STALE after > around 30secs. The neighbor entry remains in this state till a > packet needs to be forwarded to this neighbor. The first time a > node sends a packet to a neighbor whose entry is STALE, the sender > changes the state to DELAY and sets a timer to expire in around 5 > seconds. Most routers initiate moving the state from STALE to DELAY > by punting a copy of the data packet to CPU so that the sender can > reinitiate the Neighbor discovery process. This patently can be > quite CPU and buffer intensive if the neighbor cache size is huge. This could be. But the WG did not report such specific details in terms of actual problems reported from deployments. Care to say more about what these "most implementations" are and how common they are? And are they the *only* way to implement this feature, or have other vendors chosen different implementations without this limitation? That said, I could add the following to the document: Routers implementing NUD (for neighboring destinations) will need to process neighbor cache state changes such as transitioning entries from REACHABLE to STALE. How this capability is implemented may impact the scalabability of ND on a router. For example, one possible implementation is to have the forwarding operation detect when an ND entry is referenced that needs to transition from REACHABLE to STALE, by signalling an event that would need to be processed by the software processor. Such an implementation could increase the load on the service processor much in the same way that a high rate of ARP requests have led to problems on some routers. > Minor Issues: > 1. Sec 2 - Terminology should define Address Resolution as this > seems to be the core issue that the draft is discussing. > Address Resolution: Address resolution is the process through which > a node determines the link-layer address of a neighbor given only > its IP address. In IPv6, address resolution is performed as part > of Neighbor Discovery [RFC4861], Section 7.2. How about: the process of determining the link-layer address corresponding to a given IP address. In IPv4, address resolution is performed by ARP ; in IPv6, it is provided by Neighbor Discovery (ND) . > 2. In Sec 7.1 you mention that routers need to drop all transit > traffic when there is no response received for an ARP/ND > request. You should mention that in addition to this, routers also > need to send an ICMP host unreachable error packet back to the > sender. ICMP error packets are generated in the control card > CPU. So, if the CPU has to generate a high number of such ICMP > errors then this can load the CPU. The whole process can be quite > CPU as well as buffer intensive. The CPU/buffer overload is usually > mitigated by rate limiting the number of ICMP errors generated. Added: "and may send an ICMP destination unreachable message as well." > 3. In Sec 7.1 you mention that the entire ARP/ND process can be > quite CPU intensive since transit data traffic needs to be queued > while the address resolution is underway. You could mention that > this is mitigated by offloading the queuing part to the line card > CPUs so that the CPU on the control card is not inundated with such > packets. This obviously would only work on distributed systems that > have separate CPUs on the line cards and the main card. There are many things one could say about ARP implementations. But that is not the purpose of this document. It is really about outlining the problems... So I think the above is getting too detailed. > 4. Sec 7.1 should mention that this could be used as a DoS attack > wherein the attacker sends a high volume of packets for which ARPs > need to be resolved. This could result in genuine packets that need > to resolve ARPs getting dropped as there is only a finite rate at > which packets are sent to CPU for ARP resolution. Again this is > both CPU and buffer intensive. Again, I don't think this document needs to cover all aspects of ND. > 5. Sec 7.2 discusses issues with address resolution mechanism in > IPv6. I think its useful for this draft to discuss the fact that > unlike IPv4, IPv6 has subnets that are /64. This number is quite > large and will perhaps cover trillions of IP addresses, most of > which would be unassigned. Thus simplistic IPv6 ND implementations > can be vulnerable to attacks which inundates the CPU with huge > requests to perform address resolution for a large number of IPv6 > addresses, most of which are unassigned. As a result of this > genuine IPv6 devices will not be able to join the network. You > might want to refer to RFC 6583 for more details. Ditto. > 6. The last paragraph of Sec 7.3 says the following: > "Finally, IPv6 and IPv4 are often run simultaneously and in parallel > on the same network, i.e., in dual-stack mode. In such > environments, the IPv4 and IPv6 issues enumerated above compound > each other." > While I understand the sentiment behind the above statement, I fail > to see how this is related to the MAC problem being described in > Sec 7.3. The MAC scaling is a function of the total number of > unique MACs that the system has to learn and is orthogonal to the > presence of IPv4 or IPv6. I read this statement to mean that > something extra happens in the dual stack mode which exacerbates > the MAC problem even further. This I believe is patently not the > case. That paragraph was intended to cover all of 7.1 and 7.2, and not be in 7.3. I'll move it. > 7. Sec 11 - Security Considerations should at the very least give > pointers to references on issues related to ARP security > vulnerabilities. I don't see IPv6 ND mentioned at all. Since ND > relies on ICMPv6 and does not run directly over layer 2, there > could possibly be security concerns specific to ND in the data > center environments that don't apply to ARP. This document ought to > discuss those so that ARMD (or some other WG) can look at solutions > addressing those concerns. Actually, I disagree somewhat. This document doesn't need to get into all the security issues of ARP and/or ND. For one thing, they did not come up as "problems" in ARMD. :-) I will put in pointers to the ND security considerations section. How about I add the following sentence: Security considerations for Neighbor Discovery are discussed in and . > 8. Should it be mentioned in the document somewhere (sec 11?) that > data center administrators can configure ACLs to filter packets > addressed to unallocated IPv6 addresses? Folks can consider the > valid IPv6 address ranges and filter out packets that use the > unallocated addresses. Doing this will avoid unnecessary ARP > resolution for invalid IPv6 addresses. The list of the IPv6 > addresses that are legitimate and should be permitted is small and > maintainable because of IPv6's address > hierarchy. http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml > gives a list of large address blocks that have been allocated by > IANA. IMO no. This goes beyond the scope of this document. > Cheers, Manav Thanks again for your detailed review!! Thomas From narten@us.ibm.com Wed Aug 29 07:58:54 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 4BE8521F8646 for ; Wed, 29 Aug 2012 07:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 s65ZzAwW9Mdq for ; Wed, 29 Aug 2012 07:58:53 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id B1AEA21F8667 for ; Wed, 29 Aug 2012 07:58:52 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 29 Aug 2012 10:58:51 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 29 Aug 2012 10:58:49 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 3BACE6E8041; Wed, 29 Aug 2012 10:58:48 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7TEwlCk118912; Wed, 29 Aug 2012 10:58:47 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7TEwlZN010479; Wed, 29 Aug 2012 10:58:47 -0400 Received: from cichlid.raleigh.ibm.com ([9.80.31.201]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q7TEwk25010315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 10:58:47 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q7TEwgxI011886; Wed, 29 Aug 2012 10:58:42 -0400 Message-Id: <201208291458.q7TEwgxI011886@cichlid.raleigh.ibm.com> To: "Bhatia, Manav (Manav)" In-reply-to: <7C362EEF9C7896468B36C9B79200D8350D06450BB6@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D063A0AF5@INBANSXCHMBSA1.in.alcatel-lucent.com> <201208272124.q7RLOnx7015943@cichlid.raleigh.ibm.com> <7C362EEF9C7896468B36C9B79200D8350D06450BB6@INBANSXCHMBSA1.in.alcatel-lucent.com> Comments: In-reply-to "Bhatia, Manav (Manav)" message dated "Tue, 28 Aug 2012 13:50:59 +0530." Date: Wed, 29 Aug 2012 10:58:42 -0400 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12082914-7182-0000-0000-0000026F8A71 X-Mailman-Approved-At: Wed, 29 Aug 2012 08:02:53 -0700 Cc: "rtg-dir@ietf.org" , "armd@ietf.org" , "draft-ietf-armd-problem-statement.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-armd-problem-statement-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:58:54 -0000 "Bhatia, Manav (Manav)" writes: > Thanks, the proposed text is much better. > However, the draft still says "multicast frames do not necessarily > need to be sent to all parts of the network". I could be missing > something but there still seems to be some disconnect because in > the context of L2, multicast frames will be sent to all parts of > the network. L2 IGMP snooping may be taking place, which can then result in multicast traffic not being forwarded everywhere in the L2 broadcst domain... > > > > > 2. Sec 7.1 begins with the following text: > > > > > "One pain point with large L2 broadcast domains is that the routers > > > connected to the L2 domain need to process "a lot of" ARP traffic." > > > > > I am not sure if this is correct with how an L2 broadcast domain has > > > been defined in Sec 2. I would wager that a bigger pain point for a > > > large L2 broadcast domain would be handling unknown unicast traffic > > > that needs to get flooded, instead of dealing with the "ARP" > > > traffic. I am aware of very very large L2 broadcast domains that > > > have no ARP/ND scaling problems. Would it then make more sense to > > > replace the L2 broadcast domain with an ARP/ND domain? If Yes, then > > > ARP/ND domain too needs to be defined in Sec 2. > > > > The issue (as has been discussed in ARMD) is specifically the ARP > > processing load (and not unknown unicast traffic). In typical > > implementations, ARP processing is done by a service processor with > > limited capacity. The cited problem is that the amount of ARP traffic > > places a significant load on that processor. > > > > This is explained in the next pargraph. How about I add the following > > sentence to the 2nd paragraph.: > > > > In some deployments, limitations on the rate of ARP processing > > have been cited as being a problem. > > > > Does that work? > Yes it does as long as you remove the original line that I had quoted. Removing that line IMO removes something essential. It is the case that on some routers (i.e., devices at the edge of an L2 boundary) do not have sufficient resources to process "a lot of ARP traffic". "a lot" is in quotes because we don't have an exact figure for what that is. This is one of the key points to come out of the ARMD effort. What exactly do you object to in that sentence? > > > > > 3. Sec 7.1 seems to suggest that Gratuitous ARPs pre-populate ARP > > > caches on the neighboring devices. Without an explicit description > > > of what a neighboring device is, I would presume that this also > > > includes edge/core routers. In that case this statement is not > > > entirely correct as I am aware of routers that will by default not > > > pre-populate their ARP caches on receiving Gratuitous ARPs. > > > > Right. The spec says "don't do this". But I believe it was asserted > > that some implementations do this. That said, I'm not aware of any > > such implementations. I would be willing to remove this sentence in > > the absence of known implementations of this. To clarify, the current text says "Some routers can be configured to broadcast periodic gratuitous ARPs." This statement is true, and presumably you are not objecting to that. right? Note also that Warren Kumari (http://www.ietf.org/mail-archive/web/armd/current/msg00489.html) reports the Cisco IOS at one point could be configured to pre-populate ARP caches via received gratuitous ARPs. > This clearly is not the default behavior for several core/edge > router implementations that I am aware of. So at best there could > be a subset of routers that do this. Which I believe is consistent with the current text saying "some routers". > In which case you need to fix > the text that claims that *all* routers pre-populate ARP caches > upon receiving Gratuitous ARPs. How about I change the sentence: Gratuitous ARPs, broadcast to all nodes in the L2 broadcast domain, can also pre-populate ARP caches on neighboring devices, further reducing ARP traffic. to: Gratuitous ARPs, broadcast to all nodes in the L2 broadcast domain, may in some cases also pre-populate ARP caches on neighboring devices, further reducing ARP traffic. But it is not believed that pre-population of ARP entries is supported by most implementations, as the ARP specification recommends only that pre-existing ARP entries be updated upon receipt of ARP messages; it does not call for the creation of new entries when none already exist. > > > 2. In Sec 7.1 you mention that routers need to drop all transit > > > traffic when there is no response received for an ARP/ND > > > request. You should mention that in addition to this, routers also > > > need to send an ICMP host unreachable error packet back to the > > > sender. ICMP error packets are generated in the control card > > > CPU. So, if the CPU has to generate a high number of such ICMP > > > errors then this can load the CPU. The whole process can be quite > > > CPU as well as buffer intensive. The CPU/buffer overload is usually > > > mitigated by rate limiting the number of ICMP errors generated. > > > > Added: > > > > "and may send an ICMP destination unreachable message as well." > Why a "may"? An implementation is violating a standard if it isn't. The might not if rate limiting says otherwise. I.e., there are times when an ICMP won't be sent that is not in violation of the spec. > > > 3. In Sec 7.1 you mention that the entire ARP/ND process can be > > > quite CPU intensive since transit data traffic needs to be queued > > > while the address resolution is underway. You could mention that > > > this is mitigated by offloading the queuing part to the line card > > > CPUs so that the CPU on the control card is not inundated with such > > > packets. This obviously would only work on distributed systems that > > > have separate CPUs on the line cards and the main card. > > > > There are many things one could say about ARP implementations. But > > that is not the purpose of this document. It is really about outlining > > the problems... So I think the above is getting too detailed. > > > > > 4. Sec 7.1 should mention that this could be used as a DoS attack > > > wherein the attacker sends a high volume of packets for which ARPs > > > need to be resolved. This could result in genuine packets that need > > > to resolve ARPs getting dropped as there is only a finite rate at > > > which packets are sent to CPU for ARP resolution. Again this is > > > both CPU and buffer intensive. > > > > Again, I don't think this document needs to cover all aspects of ND. > > > > > 5. Sec 7.2 discusses issues with address resolution mechanism in > > > IPv6. I think its useful for this draft to discuss the fact that > > > unlike IPv4, IPv6 has subnets that are /64. This number is quite > > > large and will perhaps cover trillions of IP addresses, most of > > > which would be unassigned. Thus simplistic IPv6 ND implementations > > > can be vulnerable to attacks which inundates the CPU with huge > > > requests to perform address resolution for a large number of IPv6 > > > addresses, most of which are unassigned. As a result of this > > > genuine IPv6 devices will not be able to join the network. You > > > might want to refer to RFC 6583 for more details. > > > > Ditto. > I am fine with your resolution to the comments 3 and 4. However, I > believe that 5 ought to be discussed. This document is about ARP/ND > issues that folks are either seeing or will see in large data > centers. To clarify: "are seeing". We can speculate at length for what problems will be seen in the future. :-) > Given this, I don't see why this should not even be discussed in > this draft. I think its quite reasonable to address the above > mentioned aspect of IPv6 ND and one of way getting attention to > issue is by discussing this here in this draft. The issue you raise above is fully documented in RFC 6583, which I have added to the references (per my previous note). > > > 7. Sec 11 - Security Considerations should at the very least give > > > pointers to references on issues related to ARP security > > > vulnerabilities. I don't see IPv6 ND mentioned at all. Since ND > > > relies on ICMPv6 and does not run directly over layer 2, there > > > could possibly be security concerns specific to ND in the data > > > center environments that don't apply to ARP. This document ought to > > > discuss those so that ARMD (or some other WG) can look at solutions > > > addressing those concerns. > > > > Actually, I disagree somewhat. This document doesn't need to get into > > all the security issues of ARP and/or ND. For one thing, they did not > > come up as "problems" in ARMD. :-) I will put in pointers to the ND > > security considerations section. How about I add the following > > sentence: > > > > Security considerations for Neighbor Discovery are discussed in > > and . > This should be good. I assume that this then means that there are no > additional security concerns with ARPs/ND in data centers. I don't recall any coming up in the WG. > Can you also remove the first line from the Security Consideration? > Its redundant and has already been said earlier. OK. > > > 8. Should it be mentioned in the document somewhere (sec 11?) that > > > data center administrators can configure ACLs to filter packets > > > addressed to unallocated IPv6 addresses? Folks can consider the > > > valid IPv6 address ranges and filter out packets that use the > > > unallocated addresses. Doing this will avoid unnecessary ARP > > > resolution for invalid IPv6 addresses. The list of the IPv6 > > > addresses that are legitimate and should be permitted is small and > > > maintainable because of IPv6's address > > > hierarchy. http://www.iana.org/assignments/ipv6-unicast-address- > > assignments/ipv6-unicast-address-assignments.xml > > > gives a list of large address blocks that have been allocated by > > > IANA. > > > > IMO no. This goes beyond the scope of this document. > While I don't see any harm in mentioning this, I leave it on you/WG > to decide if you want to include this or not. > I just noticed that Sec 8 - Summary, is redundant. Shouldnt that entire text be moved to either the Abstract or the Introduction? It's the last section of the document. The document needs a summary or something (summary seems more accurate than conclusions, IMO). Thomas From hadi@mojatatu.com Wed Aug 29 11:53: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 7EA3221F86D8 for ; Wed, 29 Aug 2012 11:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wj7ZHHuBI7i5 for ; Wed, 29 Aug 2012 11:53:27 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF4F921F86CA for ; Wed, 29 Aug 2012 11:53:27 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1971997obb.31 for ; Wed, 29 Aug 2012 11:53:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=k3PMe80Cq0hny0XsEDgxf4M97sV683YMIMK6d4fs/fA=; b=YmVsIWODOk9dFhO8cg5TsbaeRgyjv31R24yBLyMgv9fA6DQXdj+yB0y5Gi3Tp025ya pVUDVImeSOaEOgRiOAk8FbGg589cqSAWhSBg8A83rKqlmkHhnkRbcyRYP9RdkdQDK49z 5bvIQzpJPNSt6AToLyBQuTIVFC1snFImZygpOxE2j2U4khlX93DxqEc8mRlIWQ5VRdy5 eR0Ha49Izb0NaKCaT6S+Le+ud4m4Q0ySOxU6rYAabMQiNylnD7bqkkACttCdQmu+Ftmt 3AlwZuC0Z3uyYYF7+PGY0js3CyGr6jBKuy1EJpZDE5RTjLQVaNwgMx0JrsO53sRWID9K h8Hg== Received: by 10.60.171.138 with SMTP id au10mr2289720oec.39.1346266407476; Wed, 29 Aug 2012 11:53:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.97.71 with HTTP; Wed, 29 Aug 2012 11:53:07 -0700 (PDT) In-Reply-To: <003f01cd85a8$13494020$39dbc060$@olddog.co.uk> References: <003f01cd85a8$13494020$39dbc060$@olddog.co.uk> From: Jamal Hadi Salim Date: Wed, 29 Aug 2012 14:53:07 -0400 Message-ID: To: Daniel King Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn7EXYswPmED7E7oredCQnaoPoJSOzPLNzDOQ4WyUNPjapxvlmC021SxQGpe8qEUxLgKMdo Cc: rtg-dir@ietf.org, draft-ietf-pce-hierarchy-fwk@tools.ietf.org, pce-chairs@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-hierarchy-fwk-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:53:28 -0000 Acked-By: Me cheers, jamal On Wed, Aug 29, 2012 at 1:35 AM, Daniel King wrote: > Dear Jamal, Martin, Donald and Joerg, > > Thank you for your reviews and comments of draft-ietf-pce-hierarchy-fwk. We > have addressed all the outstanding comments and recently uploaded a new (05) > version of the document: > > http://tools.ietf.org/html/draft-ietf-pce-hierarchy-fwk-05 > > Kind Regards, > H-PCE Authors > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: 18 August 2012 13:55 > To: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; pce-chairs@tools.ietf.org; > draft-ietf-pce-hierarchy-fwk@tools.ietf.org; julien.meuric@orange.com > Subject: RtgDir review: draft-ietf-pce-hierarchy-fwk-04.txt > > Hi, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, 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-pce-hierarchy-fwk-04.txt > Reviewer: Jamal Hadi Salim > Review Date: 2012-08-18 > IETF LC End Date: 2012-08-24 > Intended Status: Informational > > Summary: > This document is basically ready for publication, but has minor but > important readability nits that should be considered prior to publication. > > Comments: > The document describes how the PCE architecture can be extended through the > use of hierarchical relationship between domains to compute an optimum path > over a sequence of domains. > The draft is well written with good clarity on the purpose and functionality > of the intended messages. > > > Major Issues: > None > > Minor Issues: > None > > Nits: > 1) The term "antonymous" appears 5 times it almost made me believe it was > intended. I think that should be "autonomous". > > 2) Section 1.3.1 > "See Section 5.1" should be "See Section 4.1" > > 3) Section 1.3.2.1 > "Within a Carrier's Carrier ..." > should be: > "Within a Carrier's carrier .." > i.e second carrier is all lower-case > > 4) Section 2.2. > Unnecessary empty line after: > "from its entry BNs to its exit BNs that connect to the rest of the" > > 5) Section 4.6.2 > > i) "described in Section 5.6.1" > should be: > "described in Section 4.6.1" > > ii) "(See Section 5.5)" > should be: > "(See Section 4.5)" > > 6) Section 4.7 > ".. path to the egress. The child PCE should return the relevant .." > should be: > ".. path to the egress, the child PCE should return the relevant .." > > cheers, > jamal > From adrian@olddog.co.uk Thu Aug 30 08:10:13 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 AE4C021F8535 for ; Thu, 30 Aug 2012 08:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, 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 1W-GE9bsoBPr for ; Thu, 30 Aug 2012 08:10:13 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2C21F84B3 for ; Thu, 30 Aug 2012 08:10:12 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7UFABlO008144 for ; Thu, 30 Aug 2012 16:10:11 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7UFAA5J008123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 30 Aug 2012 16:10:10 +0100 From: "Adrian Farrel" To: Date: Thu, 30 Aug 2012 16:10:10 +0100 Message-ID: <211c01cd86c1$8d0afc90$a720f5b0$@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: Ac2GwYnzZWh0ab4zQS6gVAVjtgkFTA== Content-Language: en-gb Subject: [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: Thu, 30 Aug 2012 15:10:13 -0000 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 rcallon@juniper.net Thu Aug 30 08:31: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 38EAC21F858E for ; Thu, 30 Aug 2012 08:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.045 X-Spam-Level: X-Spam-Status: No, score=-106.045 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB22=0.948, 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 o+m3vcro4tIP for ; Thu, 30 Aug 2012 08:31:13 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF1E21F857D for ; Thu, 30 Aug 2012 08:31:08 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUD+HO0Uw7/6hIwQ4duv/ACvER3lGmbY2@postini.com; Thu, 30 Aug 2012 08:31:09 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 30 Aug 2012 08:30:44 -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; Thu, 30 Aug 2012 11:30:43 -0400 From: Ross Callon To: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" Date: Thu, 30 Aug 2012 11:30:41 -0400 Thread-Topic: [RTG-DIR] Routing directorate Gathering / Social Atlanta Thread-Index: Ac2GwYnzZWh0ab4zQS6gVAVjtgkFTAAAogtA 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 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: Thu, 30 Aug 2012 15:31:17 -0000 My personal opinion:=20 This is a good idea. Wednesday is a good night.=20 We should pick a restaurant that has good beer, so that we won't feel bad m= issing the WG chairs beer night. (I am assuming that Atlanta must have at l= east two restaurants that have a good choice of beer).=20 Thanks, Ross -----Original Message----- From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf = Of Adrian Farrel Sent: Thursday, August 30, 2012 11: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 Direct= orate (and their saintly secretaries) to all meet up in Atlanta. After some discussion, we think that dinner would be more social than business, and th= at seems entirely appropriate. No evening at an IETF ever works well for every= one, but we would like to suggest Wednesday after the Administrative Plenary. Th= is will conflict with the WG chairs' beer evening, and we will understand if s= ome 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 yo= u 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 manav.bhatia@alcatel-lucent.com Thu Aug 30 08:36:30 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 BA81321F858F; Thu, 30 Aug 2012 08:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.422 X-Spam-Level: X-Spam-Status: No, score=-9.422 tagged_above=-999 required=5 tests=[AWL=1.177, 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 Alx9RafWVpcP; Thu, 30 Aug 2012 08:36:29 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C972421F857E; Thu, 30 Aug 2012 08:36:29 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7UFaL78021970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 10:36:24 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7UFaJux009818 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Aug 2012 21:06:20 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 30 Aug 2012 21:06:19 +0530 From: "Bhatia, Manav (Manav)" To: Thomas Narten Date: Thu, 30 Aug 2012 21:06:25 +0530 Thread-Topic: RtgDir review: draft-ietf-armd-problem-statement-03 Thread-Index: Ac2F9tEdiNnE460+QqiYmVD1vas4CwAAbyhQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D064CAF3A@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D063A0AF5@INBANSXCHMBSA1.in.alcatel-lucent.com> <201208272124.q7RLOnx7015943@cichlid.raleigh.ibm.com> <7C362EEF9C7896468B36C9B79200D8350D06450BB6@INBANSXCHMBSA1.in.alcatel-lucent.com> <201208291458.q7TEwgxI011886@cichlid.raleigh.ibm.com> In-Reply-To: <201208291458.q7TEwgxI011886@cichlid.raleigh.ibm.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-dir@ietf.org" , "armd@ietf.org" , "draft-ietf-armd-problem-statement.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-armd-problem-statement-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:36:30 -0000 Hi Thomas, >=20 > > However, the draft still says "multicast frames do not necessarily =20 > > need to be sent to all parts of the network". I could be missing =20 > > something but there still seems to be some disconnect=20 > because in the=20 > > context of L2, multicast frames will be sent to all parts of the=20 > > network. >=20 > L2 IGMP snooping may be taking place, which can then result=20 > in multicast traffic not being forwarded everywhere in the L2=20 > broadcst domain... Yes, that's correct. So youre suggesting that IGMP snooping will help reduc= e "ARP" traffic in case of IPv6. Do hosts send out MLD reports for the link= local addresses that they expect to receive the Neighbor Discovery message= s on? If they don't, then snooping will be of no help in reducing IPv6 ND t= raffic that the draft is discussing in that section. [clipped] >=20 > > Yes it does as long as you remove the original line that I had > quoted. >=20 > Removing that line IMO removes something essential. It is the=20 > case that on some routers (i.e., devices at the edge of an L2=20 > boundary) do not have sufficient resources to process "a lot=20 > of ARP traffic". "a lot" is in quotes because we don't have=20 > an exact figure for what that is. This is one of the key=20 > points to come out of the ARMD effort. >=20 > What exactly do you object to in that sentence? My concern with the opening sentence of Sec 7.1 is that it generalizes larg= e L2 domains and makes a sweeping statement that seems to suggest that all = routers in large L2 domains need to process "a lot of " ARP traffic. This i= s patently incorrect. As I have said earlier, this issue is specific to L2 = domains that see a lot of ARP/ND traffic and is not true in general for all= large L2 domains.=20 [clipped] > > >=20 > > > Right. The spec says "don't do this". But I believe it=20 > was asserted=20 > > > that some implementations do this. That said, I'm not=20 > aware of any=20 > > > such implementations. I would be willing to remove this=20 > sentence in=20 > > > the absence of known implementations of this. >=20 > To clarify, the current text says "Some routers can be=20 > configured to broadcast periodic gratuitous ARPs." >=20 > This statement is true, and presumably you are not objecting=20 > to that. right? Yes, I am not. [clipped] >=20 > How about I change the sentence: >=20 > Gratuitous ARPs, broadcast to all nodes in the L2 broadcast > domain, can also pre-populate ARP caches on neighboring devices, > further reducing ARP traffic. >=20 > to: >=20 > Gratuitous ARPs, broadcast to all nodes in the L2 broadcast > domain, may in some cases also pre-populate ARP caches on > neighboring devices, further reducing ARP traffic. But it is not > believed that pre-population of ARP entries is supported by most > implementations, as the ARP specification target=3D"RFC0826"> recommends only that pre-existing ARP > entries be updated upon receipt of ARP messages; it does not call > for the creation of new entries when none already exist. Sounds good. >=20 > > > > 2. In Sec 7.1 you mention that routers need to drop all=20 > transit =20 > > > > traffic when there is no response received for an=20 > ARP/ND request.=20 > > > > You should mention that in addition to this, routers=20 > also need to=20 > > > > send an ICMP host unreachable error packet back to the sender.=20 > > > > ICMP error packets are generated in the control card =20 > CPU. So, if=20 > > > > the CPU has to generate a high number of such ICMP errors then=20 > > > > this can load the CPU. The whole process can be quite =20 > CPU as well=20 > > > > as buffer intensive. The CPU/buffer overload is usually=20 > mitigated=20 > > > > by rate limiting the number of ICMP errors generated. > > >=20 > > > Added: > > >=20 > > > "and may send an ICMP destination unreachable message as well." >=20 > > Why a "may"? An implementation is violating a standard if it isn't. >=20 > The might not if rate limiting says otherwise. I.e., there=20 > are times when an ICMP won't be sent that is not in violation=20 > of the spec. Aah, ok.=20 [clipped] > > >=20 > > > > 5. Sec 7.2 discusses issues with address resolution=20 > mechanism in =20 > > > > IPv6. I think its useful for this draft to discuss the=20 > fact that =20 > > > > unlike IPv4, IPv6 has subnets that are /64. This number=20 > is quite =20 > > > > large and will perhaps cover trillions of IP addresses,=20 > most of =20 > > > > which would be unassigned. Thus simplistic IPv6 ND=20 > implementations =20 > > > > can be vulnerable to attacks which inundates the CPU with huge =20 > > > > requests to perform address resolution for a large=20 > number of IPv6 =20 > > > > addresses, most of which are unassigned. As a result of this =20 > > > > genuine IPv6 devices will not be able to join the network. You =20 > > > > might want to refer to RFC 6583 for more details. > > >=20 > > > Ditto. >=20 > > I am fine with your resolution to the comments 3 and 4. However, I =20 > > believe that 5 ought to be discussed. This document is=20 > about ARP/ND =20 > > issues that folks are either seeing or will see in large data =20 > > centers. >=20 > To clarify: "are seeing". We can speculate at length for what=20 > problems will be seen in the future. :-) If the scope is only the former, then I am ok with you not considering poin= t 5. >=20 > > Given this, I don't see why this should not even be=20 > discussed in this=20 > > draft. I think its quite reasonable to address the above mentioned=20 > > aspect of IPv6 ND and one of way getting attention to issue is by=20 > > discussing this here in this draft. >=20 > The issue you raise above is fully documented in RFC 6583,=20 > which I have added to the references (per my previous note). Which is indeed very helpful. [clipped] > > >=20 > > > Security considerations for Neighbor Discovery are=20 > discussed in > > > and target=3D"RFC6583">. >=20 > > This should be good. I assume that this then means that=20 > there are no =20 > > additional security concerns with ARPs/ND in data centers. >=20 > I don't recall any coming up in the WG. Ok. [clipped] >=20 > > I just noticed that Sec 8 - Summary, is redundant. Shouldnt that > entire text be moved to either the Abstract or the Introduction? >=20 > It's the last section of the document. The document needs a=20 > summary or something (summary seems more accurate than=20 > conclusions, IMO). I will not argue on this! :-) Cheers, Manav > = From jdrake@juniper.net Thu Aug 30 09:09: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 68D4321F8598 for ; Thu, 30 Aug 2012 09:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.318 X-Spam-Level: X-Spam-Status: No, score=-5.318 tagged_above=-999 required=5 tests=[AWL=0.333, 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 pYUqOllICePc for ; Thu, 30 Aug 2012 09:09:29 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id BEA9621F8570 for ; Thu, 30 Aug 2012 09:09:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUD+QNyqWxuKUXG9mUzhSv88cNJbfRO89@postini.com; Thu, 30 Aug 2012 09:09:28 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; Thu, 30 Aug 2012 08:15:14 -0700 From: John E Drake To: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" Date: Thu, 30 Aug 2012 08:15:12 -0700 Thread-Topic: [RTG-DIR] Routing directorate Gathering / Social Atlanta Thread-Index: Ac2GwYnzZWh0ab4zQS6gVAVjtgkFTAAAJaiw Message-ID: <5E893DB832F57341992548CDBB333163A63288F653@EMBX01-HQ.jnpr.net> 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 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: Thu, 30 Aug 2012 16:09:29 -0000 Um, will you and Stewart be attending?=20 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 >=20 > Hi, >=20 > 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. >=20 > 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). >=20 > Thanks > Adrian and Stewart >=20 >=20 From rcallon@juniper.net Thu Aug 30 10:22:30 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 9B47B21F854B for ; Thu, 30 Aug 2012 10:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.038 X-Spam-Level: X-Spam-Status: No, score=-106.038 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB22=0.948, 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 W12toh30P0eS for ; Thu, 30 Aug 2012 10:22:30 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBF21F8545 for ; Thu, 30 Aug 2012 10:22:30 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUD+hVIbfjrblZ5OJLzzFf2YPYcjuUH0R@postini.com; Thu, 30 Aug 2012 10:22:30 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 30 Aug 2012 10:20:52 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 30 Aug 2012 10:20:49 -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; Thu, 30 Aug 2012 13:20:46 -0400 From: Ross Callon To: John E Drake , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" Date: Thu, 30 Aug 2012 13:20:45 -0400 Thread-Topic: [RTG-DIR] Routing directorate Gathering / Social Atlanta Thread-Index: Ac2GwYnzZWh0ab4zQS6gVAVjtgkFTAAAJaiwAARk4qA= Message-ID: References: <211c01cd86c1$8d0afc90$a720f5b0$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A63288F653@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A63288F653@EMBX01-HQ.jnpr.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 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: Thu, 30 Aug 2012 17:22:30 -0000 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?=20 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 >=20 > Hi, >=20 > 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. >=20 > 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). >=20 > Thanks > Adrian and Stewart >=20 >=20 From adrian@olddog.co.uk Thu Aug 30 11:30:07 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 8420B21F85C4 for ; Thu, 30 Aug 2012 11:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, 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 LC0-Ln8YsEKU for ; Thu, 30 Aug 2012 11:30:06 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4691021F85C3 for ; Thu, 30 Aug 2012 11:30:06 -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 q7UIU4H9019163; Thu, 30 Aug 2012 19:30:04 +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 q7UIU3Ef019150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Aug 2012 19:30:04 +0100 From: "Adrian Farrel" To: "'Ross Callon'" , "'John E Drake'" , References: <211c01cd86c1$8d0afc90$a720f5b0$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A63288F653@EMBX01-HQ.jnpr.net> In-Reply-To: Date: Thu, 30 Aug 2012 19:30:03 +0100 Message-ID: <21cc01cd86dd$799429e0$6cbc7da0$@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/6eHUfWQIyMOPOAepIeeSXUJFK8A== 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: Thu, 30 Aug 2012 18:30:07 -0000 I can safely give you two answers. Yes and No. Adrian > -----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 manav.bhatia@alcatel-lucent.com Thu Aug 30 17:52:47 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 685CF21F84A5; Thu, 30 Aug 2012 17:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.488 X-Spam-Level: X-Spam-Status: No, score=-7.488 tagged_above=-999 required=5 tests=[AWL=-0.889, 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 9PlHbGcycIFJ; Thu, 30 Aug 2012 17:52:46 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D28E721F848F; Thu, 30 Aug 2012 17:52:46 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q7V0qeog018953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 19:52:43 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7V0qaRR008071 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Aug 2012 06:22:38 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 31 Aug 2012 06:22:36 +0530 From: "Bhatia, Manav (Manav)" To: Thomas Narten Date: Fri, 31 Aug 2012 06:22:50 +0530 Thread-Topic: RtgDir review: draft-ietf-armd-problem-statement-03 Thread-Index: Ac2F9tEdiNnE460+QqiYmVD1vas4CwAAbyhQAEZVgVA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D064CAF6E@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D063A0AF5@INBANSXCHMBSA1.in.alcatel-lucent.com> <201208272124.q7RLOnx7015943@cichlid.raleigh.ibm.com> <7C362EEF9C7896468B36C9B79200D8350D06450BB6@INBANSXCHMBSA1.in.alcatel-lucent.com> <201208291458.q7TEwgxI011886@cichlid.raleigh.ibm.com> <7C362EEF9C7896468B36C9B79200D8350D064CAF3A@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D064CAF3A@INBANSXCHMBSA1.in.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "draft-ietf-armd-problem-statement.all@tools.ietf.org" , "armd@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-armd-problem-statement-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 00:52:47 -0000 =20 > >=20 > > What exactly do you object to in that sentence? >=20 > My concern with the opening sentence of Sec 7.1 is that it=20 > generalizes large L2 domains and makes a sweeping statement=20 > that seems to suggest that all routers in large L2 domains=20 > need to process "a lot of " ARP traffic. This is patently=20 > incorrect. As I have said earlier, this issue is specific to=20 > L2 domains that see a lot of ARP/ND traffic and is not true=20 > in general for all large L2 domains.=20 Some more clarification. There are large L2 domains that might see lot of ARP/ND traffic but will NO= T process them. Such domains will treat all such traffic as regular bcast/m= cast traffic and will flood it appropriately. The draft seems to suggest th= at large L2 domains have an issue because they need to process all such tra= ffic which could lead the reader to believe that all such traffic is punted= to the CPU where its processed. However in reality, most large L2 domains = are oblivious to whether the bcast traffic is ARP or something else. Handli= ng this traffic is not an issue at all. Its dealing with the unlearnt traff= ic that's an issue in such domains as the source MACs need to be learnt. If= the L2 table is hash based then dealing with collisions, etc is another pr= oblem. If its CAM based then the size is often a limitation on the number o= f MACs that can be learnt. Cheers, Manav From adrian@olddog.co.uk Fri Aug 31 10:02: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 8D81F21F8442 for ; Fri, 31 Aug 2012 10:02:50 -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 6kuIsBF9IF6F for ; Fri, 31 Aug 2012 10:02:49 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEC021F863C for ; Fri, 31 Aug 2012 10:02:41 -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 q7VH2eKP003418; Fri, 31 Aug 2012 18:02:40 +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 q7VH2a2O003394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2012 18:02:37 +0100 From: "Adrian Farrel" To: , References: In-Reply-To: Date: Fri, 31 Aug 2012 18:02:36 +0100 Message-ID: <23a801cd879a$6ca18350$45e489f0$@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: AQEC0dmwGXPAJW22HLQkZVItsUZXn5kJkKjw Content-Language: en-gb Subject: [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 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: Fri, 31 Aug 2012 17:02:50 -0000 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 ? > > - 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. > > - 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. > > - 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 ? > > - 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 " This section does not > modify processing required to support [RFC4872] and [RFC4873], and which is > reviewed in Section 3 of [RFC6689]. " and in RFC 4873/Section 3.2 "The > ASSOCIATION object is used to associate different LSPs with each other." > > - 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. > > - 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 ? > > - Section 3.1.2 and 3.2.2 no error processing is being documented whereas mis- > match in association should be considered as a generic error. > > - Section 3.3 states "Since the admission control function is outside the scope of > RSVP,..." are you sure ? 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. > > - 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 (and actually the same for RFC 4873 which relies on MBB as defined in > RFC 3209) > > - 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. ? > > - 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 ? > > - 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. > > - Section 4.2: shouldn't "error processing" being documented ? Example include > admission control where receiving node rejects the incoming Path msg if the > originating Global_ID/Ext.ASSOCIATION object isn't included, unauthorized > Global ID ? etc. but also mismatches between Association source and Global > Association source ? > > - 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 ? > > - 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. > > > 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) > > - Introduction: s/different ports/different destination (dst) ports > > - Section 2 would better refer to a "Generalization" rather than a "modification" > > - 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. > > - 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. > > > ----- > Homepage: > >