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

www.amsl.com

------=_NextPart_000_0030_01CD704F.59E26930-- From adrian@olddog.co.uk Thu Aug 2 12:34:12 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@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: Subject: DHCPv6 Prefix Pool Option 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 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list 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: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@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 Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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 X-Mailman-Approved-At: Thu, 02 Aug 2012 13:26:06 -0700 Cc: "rtg-dir@ietf.org" , "dhc-chairs@tools.ietf.org" , Ted Lemon , "dhc-ads@toools.ietf.org" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list 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 mellon@fugue.com Thu Aug 2 15:15:14 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@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) Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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:09 -0700 Cc: rtg-dir@ietf.org, "dhc-chairs@tools.ietf.org Chairs" , "" , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list 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 acee.lindem@ericsson.com Fri Aug 3 10:54:58 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@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 Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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 X-Mailman-Approved-At: Fri, 03 Aug 2012 11:55:09 -0700 Cc: "rtg-dir@ietf.org" , "dhc-chairs@tools.ietf.org Chairs" , "" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list 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 Mon Aug 6 06:28:00 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@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) Subject: Re: [RTG-DIR] DHCPv6 Prefix Pool Option 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:43:11 -0700 Cc: "rtg-dir@ietf.org" , "dhc-chairs@tools.ietf.org Chairs" , "" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list 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.