operated with packet loss no longe= r than app 30ms (link/node failure), irrespective of FIB size.

- if your OSPF code is 500K lines of code, you must have a lot of commen= ts and ascii art in that code ;-) - usually a link state protocol has = a code complexity of 50-90K LoC, same goes for BGP.

if we want to go beyond that we have to perhaps adjust some of the backo= ff and pacing timers (some of them are unchanged since 15 years)= and would benefit from lowering for = faster initial LSDB sync etc.

From: rtgwg <rtgwg-bounc= es@ietf.org> on behalf of liu.bin21@zte.com.cn <liu.bin21@zte.com.cn&= gt;
Sent: Wednesday, July 23, 2014 4:00
To: curtis@ipv6.occnc.com
Cc: adrian@olddog.co.uk; ytsun@bjtu.edu.cn; rtgwg-chairs@tools.ietf.= org; rtgwg@ietf.org
Subject: Re: Reply to comments -- Comparison between FAR and OSPF - = FRR

Hello Curtis,

Thank you for your comments. But from what did you get conclusion o= f 'research projects'? We not only have a deployment experience but also st= rict large-scale system data analysis.

Following is my reply:

'No SPF is required for FRR to provide= protection, restoring traffic flow though sometimes on a suboptimal path.'=
--Is FRR only used within domain? If s= o, it can be counted as a drawback. And LDP FRR cannot guarantee that the c= alculated path is the optimal path, leading to the emergence of new link co= ngestion. But FAT TREE architecture network is a non-blocking network.

'One commercial CSPF measured about a = decade ago completed in 30-40msec on a test topology of 450. That was= on a 300 MHz or less PPC or Pentium-2.
Todays processors are an order of magn= itude faster, so we could expect (with order NlogN scaling of SPF) to get a= bout the same SPF time on a topology of 4K or more nodes with no improvemen= ts in software.'
--As seen from the above CSPF business= application data, there is a linear correlation between the convergence ti= me and the number of topologies, while it is not sensitive to the FAR.

well the question is: does it mat= ter ? - we can crunch a single SPF graph consisting

of app 1000 nodes in 1m= s. i haven't seen concerns from any of my customers

about that figure.

To compare the FRR and FRR, the w= orking process of the LDP FRR technology is described as follows:
1) Running LDP protocol in the network= , it works as DU (downstream independent) label distribution + orderly = label control + free label retention. (Disadvantage :additional protoco= l overhead)

In the above case, there are two paths= from R1 to R5, R5 initiates multi-label mapping message to the upstream. E= ventually, R2 and R3 respectively assign labels to R1 for reaching R5, amon= g which, the label distributed by R2 is the primary label, the label distributed by R3 can be used as a backup.= (Disadvantage: the irregular topology leads to complex routing and prone t= o cause more serious link block)

modern implementation of LFA, R-LFA also have got

support for policy control, such that backup-paths

which may be congested are avoided.

2) Specify one equipment port of the L= SR as the backup of another equipment port.

usually the backup decision is done on a per route-bases rather than o= n a per backup basis so your above assumption is not correct.

3) Equipment maintenance label forward= ing table: As the port backup has not been implemented, one label forwardin= g table has only one next hop and label, and the label is distributed for F= EC by the LDP peer connected to the next hop of the routing of FEC. After the port backup is implemented, if t= he next hop of a label forwarding table is the protected port, add a next h= op and label for the entry, and the label is distributed for FEC by the LDP= peer connected to the backup next hop. (Disadvantage: large protocol database overhead and processing overhe= ad)

if you are concerned about one vs. two protocols (not that i am)<= br> have a look at the recent work on segment routing - it allows

to construct SPT paths and label state programming using one

IGP protocol.

4) Equipment maintenance of the workin= g status of each port (normal/failure).

5) Packets reach the next hop, and are= forwarded to the destination according to the corresponding label forwardi= ng table.

It can be seen from the above FRR p= rocessing that FRR has the following disadvantages compared to FAR:

1) Additional protocol overhead: For t= he protection of links, nodes and paths, it is necessary to set up a backup= LSP respectively, which causes unnecessary overhead and complex protocol p= rocessing; (there is no such protocol overhead for FAR, and because FAR is based on regular topology, path prote= ction and switching process are simple.)

LFA, R-LFA are very conservative with regard to additional forwarding

state generation. most often just exisiting forwarding state is re-use= d.

2) Backup LSP failures may exist. As t= here is no protection mechanism, it cannot fast reroute when it fails; (Fat= Tree network architecture has multiple natural selection.)

3) There is a linear correlation betwe= en the convergence time and the number of topologies, while it is not sensi= tive to the FAR.

that is entirely dependent on how FRR is implemented in your dataplane= .

i may have to add that there are vendors how have chipsets which can

do FRR switchover in constant time.

4) LDP FRR cannot guarantee that the c= alculated path is the optimal path, leading to the emergence of new link co= ngestion. But FAT TREE architecture network is a non-blocking network.

Best.

Richard

--_000_140620498661196069junipernet_-- --_004_140620498661196069junipernet_ Content-Type: image/gif; name="ATT00001.gif" Content-Description: ATT00001.gif Content-Disposition: inline; filename="ATT00001.gif"; size=8239; creation-date="Wed, 23 Jul 2014 02:01:16 GMT"; modification-date="Wed, 23 Jul 2014 02:01:16 GMT" Content-ID: <_1_0A943E600A943A48000B0F5048257D1E> Content-Transfer-Encoding: base64 R0lGODlh+QHIAOcAAP////Dw8Ojo6MDAwODg4JCQkNjY2FBQUMjIyICAgAAAAKCgoLCwsNDQ0HBw cKioqLi4uHh4eCgoKEBAQJiYmGhoaCAgIIiIiFhYWGBgYDg4OBAQEDAwMEhISAgICBgYGJigoKCo qMDIyPD4+FBYWGhwcIiQkODo6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA+QHIAEAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6iyA4YDPn0CDCh1KtKjRoBgS6JyYwScDggF6/qQgUMDPAUuzat2qsUIEhBccECjYoYBAAgUS JBAwsgECAgEQaniQdYCFhgEGYPCgoK+CBwEC1+RAFwCDDAACeGggMEIFAA00MAZQYUFiBGa5at7M 2WUACBHYRoRwYEKBsQTnVlzgt+/Tg6ohWxZYwEBDuwoJPKggwQKGBbY1Ergg4cOByZ2TK1/emQGG sqIZBiDAwEGHC6gnxtaJu6SBBRU0dP9wsOCtgLgVCRhAD4GCCLjM48ufj1A3hegLBSBYEAEDheAj bZdTd5o1sIADGFSQAAUMIGAAfhHllUAGCaCnHoT0ZaihRAYwMBtEAkCQVgIPAMhVAAZGgMBCA1wA wYYvofjABRFEkMAFDDaAYUQGUGAjVTAGyRIBDiSAHAAFZOAABOg1JAADNRbAQHb0CRABcAM4MIGJ Zx24I0EDVNakkEsJ0AAEC6TlgIIPNDCmRhK8phMEEpCZUWB45mnQkxVkQAECXwYZwAIHYKUQAhUw aeeiGE3XwAA+9kQecnFmRadIhNV110EBPDDBAf+9yehCohYkQAEVlDrqqh9VShEFEwj/YIAHKx4k gAYvDpDAh7U1dGlImVK0wAQETQBkVQpQWVCvDNklgJK1LtXABugJ9gAHA2UaAAUHVCUQAwnIiZdD DUwQbX0UHMujB6IJBkB36F3QrUAbrAhBuKxq9mQHDbg6Z53AFibRAhpogAFBCWhwAQAGFCzZRQQi BEEFBbg56nAHqDrQcNgplBcHiuYrskMBIEDel/7m9CtIwXLnwQR+fcDBBH5qXNUCux7Z2W7icjpA Buci9CiXIxdNEAEUGJkQ0uQZbScCuyrbkIFR3xQA0QYRsKDUTned0IwQBJqYAUF77TQBjjFgs0Eo FhBBzyEJIPZAATBQQdkCGQCzAht0/7DA3GZr2MCCWOeNauGBJ/5RyRMi3tFvgCvOaAAFXDDA2pJn DpIBEOCdkFdZBbCBzhcnm1UCBxc0QASZ1ZeABJjDCbfmOVHQAUIMSDDBkRMSJAAFpDsUJgbngk6R ARIoYIEEzIs1kAEdMB8B1yRv8OlR2Gev/fbcF9WB6RNVsMEGzEvAQdCDfoBRArsvm8C5Fste1VgC KBCcAw4AgED5HnxAVwMXaB3tBkgQ41FEMZPhj6EKgrrE4CxydBtdQvSTruAthwDgC99XAECAAwCm IAhQn0AGUIAXRaSBAkHUleJHwBZmxYA5EZ0F87aABcwwORikHk1Q6MIebmY/NQyiEP+HSMQiGvGI SDRi7DY0qCQ68YlQdOICfUjFKuIEARsoCHgmU689eaBDF0iACa1IxjKa8YxoTKMa18jGNrrxjXCM oxznSMc6zgSGApnAbB6gAYGUZgMClImAcBIxUsnKLWhyXEtaJhDFzGwCCeASouiSl0Da8Y2oqoAm K5A/AFxgkxVYGAAcs8kPNcoAlzvLEg0wI/9RBAIT+AAoLzCZ4WzyAopk0QZuRAEI6IghBnifxh6w pgJEC4KXTGaQDIAqCujwIA1w24IQgLlBQoRgA1HgxhxQgABcYEX2kUghI8Q5CoQxAkV6ADUtIquB ENMB/1GmPGNCABBEoE0PaYAJKMT/ABZmxJo2GSdLroYANE1oPDZcYn0GwIABiKYBDMjlPOkotyUO RwMOGAB8ViIAAnj0oyANqUhHStKSmpSkTOxoA4g5AQlUZj0XGVQFOHC3iXatZBmogEQJEkwOYGCM nTEAB1qjAA/cDiEBOMDfbMpTCmSAeZXZKFPnY6UNtOYAECRAixI0RacNKgFdtdVULYIiClTgU/d0 kFQZkjKcrOwjjCTkpvACRgWl0mgDyKUBWGczylVgdmNtSVshYrvUzAYtj1EITBnyVo/E9SYD+EAD kragu+JkWm+abADUorQBFAaBedspCPF4kKSF1VQPqBBEZgUhZg5ENZ7VmlpQYwDR/051sMLrgAVa R9l+cjYB2SHADSUGMJYJbGDEAsADMqCz+qFmsjd6gHTX2ay55i21BUCmkAYAnIUgIALq8lhgbRLN ihEEtzVpbEceG1DrkqpHGADsqtIy3HaOVyYCwJllW8jemuAmABroCwdMudoKHMC2noEa5qBmSYNE gLn3dcl3lRJhmvwOkhMZAKgQ3BEEJGVuncLAM/UXAVFW+CQEWEAGHAe9jp0YJ79bwIjZ5rYSeYSZ gPsugU3FGgV8QANKe/HidNVgIWsumiUugJKXzOQmO/nJSo6ABpIM5SpXeQEKzdCgrMzlLnv5ywWg wGmflxbHgcaZRo6J3RRkkInh0f9D6TGr5wRCWpvIcGQ5PN3BvhoyaM64IW2tX4ISlbcKUCAA/hLA mNMMgMIKBAOMwV/eFBCd3m3MvBup80McOYFOO0BnEfjABgWCZYFAQL4RHG6Q8kyRClig0xPogNoE QoFPh5AgCKiVACjMEB4CQADfi1kJRsBoNGqaJne+WfKIugHxHEC1AFjAczDQugQcoAMZ+KyBO1AB QxngOeOZDAQ48IEPiJjU5LZAYgHwOpnx2tUyywyAy32AMbJaJ74uNhyPPZNk5+veOcm3vgeeISxy igFDrZWlBfBFgjv84dDEgMQnLicBTHwyekkQxDfO8Y57/OMgD7nIR07ykpv85Cj/T7nKV87ylrv8 5UxNLb4KAi4SFUSdNgGof90rn7iCFtciBMABigxzDfF7WAQpC1TWQpIGOCADp9U5TQRaEANkwKpE 1cCcXfLYJjmGbhaola4SQPSiM8d4BEjsjRgDtaS3jnHaZUh1ouoQqc+E6pwymVU7YBvqpOVY52HJ A9JF+DEOHnhVIXwFzU7HQXGVZAS41wEiYBu7LwSbA+lAeAUCUGaxaFMhkhfNLtCgB2UZIQI4a7aj c3rGEzxEFcsqtyrQpi9ZXiGYR0ChDmIBrCAgjAuqYOzwvieyMaAA1pn8lMgaeMhEYAK/ab3rJ9q5 2Mnok7TM8u1xJ/FO0to/Hp44//EsQnyKRB5VGSgxg94i/UY+qEsFaFP7p+9CrdJt0xTQQAYYEHe5 HFeuKxEYWiUvHzABERA2MWUmqIE0QEV/mRMiC6JdlaQWfzJ/C7F9L1F+L4FKCwB8P6JRFuF3QWYm v+SAQrJXEvBpm5ZiB4ABH4QSGnAfcjODNFiDNniDOJiDOliDDMBznREiEaBbzwYBBNB8FAFAHaAB b2eBJlgSu0YhfUYquhJK/dSE9VFQHfhgGeAif7YQg2NgUWiFI2EAF7B/S6QfB+KCTDgkEOAAy/YB NsMfW+dG1IE6BxBKDyACpncRxJQzYhgR+lGC0mEypgEo9BFMFtAXH1BkCNA+uf/BIPKkUgxQhh3Q AWLUfxThABpQPpzYiZ74iaAYiqIIihzgfQQEAQHmAbuXNw/hdzXyAJi4FQFgaM/0e2U3EEYoZJyD fA6gfurUhQmBXjShXoqDAIlIVEblhRkAZKp2iBGgaqEUix8HgRPwamK0EMI4E8S4EfyBP974jeAY juI4juRYjuK4eQ7xHWpRQsC4IXLjMW6jSB01fVfDXee0AaimEG0IjiZiAN/YjAmxjRrRX1Png1Ch aBEweQBpJwHQi3MIAUAjdzb2h9m4EPlXW7V1AK/RgxYQdgXRJJ6nj8UFV/8HWdbVI16hTmvYEafi AS84QvvHAIeBFcQkkw/QAe3/iFRzOEK7YjMCQCMQ9Dt/MSYeJpMzqVx/JZMHBnEVqRCOBgC9hxAc wH+p9R+19RACmREEuRAPIAF9U4llkR2DkkEVMQAvE4Y5gVkK0TL5lTEchDP5eBCRt2hVAU85+RCs xX3BUy8pNnNpVjcWEJcwkZUYsZWX5wEd2ZEv+WtkyUoDEZIJAS9h8owD8gHK05EeoBSA2ZGzlgCI 2ZEKMBnu0hCoko/5lQFzMzHdNBEh5GOYqRQMcJkW4JKJQQGJGS2jWWFMExxNOZgj6Vgl+RBIJxBh dCTO9TwLgI6fl3dqwX8D1CkRQJdvKY0q93vxVBC9+RKEeRGGGRMaWJvUtpI6/2EyvJYQDUB7fwgR P5OPE8AXRPWe8Bmf8jmf9OkXHtBHAVMXH9AgwPgZYbRfyyEi0slBfiI2ftWA9Ic0BQCg/BWcOwdg 7sk3qImXqIKAQXKaa0OdJsdMDmCg8SeegjMAIjqiJFqiJnqiKJqiKnqitdJBlJd4OgWIbUhLOhFM WMUQSTOHdbNUDphasGieFQBp0ydccfddlgOiIdgAf4YAGYCWPFU5DigAxMSgjQQBRJie8+d4h7YS SgpM8CQquyYBi+l6w/Gi6VkRqLSQvgMl34SkvuMpVHo0aaFDCBChfTEBDopyUINmCcFKY3qmDIEA SniXe5UobsoQaTGHZAhhRf9XHYIJqPT0AKzDYSSje9T1hz9pTKoipaUGqSMBkUaSZfwmE/7GKgCH EwKXGNHEdEjlqTBBAGq4EKMaE6W6Kqd6E74mqc5pngt6hLuFH/XTILlGJe35qGn2lAMhaQxDaZ6U ARyAGHdylQUxqzBRq6VzlyrBPvqlEIcRZBfRVgEwoQCAPxwqEJVSh7coZMhqEAbArAJhad6kFmrK ENSaED+HJPOSGAORqgOAoGwjQSLTrthKZ6N2r9wSWahnYguRbwwQYNaTrhFimR4wsQpwVIg2sQoL ABKrnAM3dr+FGlBDdu70WxyLEfWKVIthGG+DEKjzJM1ppXklHQD7b2QZEaD/E0yjhgFT1h8eEAEl 83dWCgED+q6pQ2dYh5jjMWuuqhwny67l9gELxAAyAwDkVm7lKRG1Oh2e4p4T4K8XVLMPkQHlZooa 4EophC0XkapLmyFNO1Az+zxtuGwdMLSacas2obZrOx9tG4Bva6tge7dFm7cbsrcqYa2MYrc1gbeC y3LMpGSq0kUCUV4lu7iUyxUGd3P4CbnfwjdNYqWV+7mWm0W09iKNWwA9axsL13Df4bWg27qu+7qw G7uyO7u0W7u2e7u4m7u6u7u827u++7vAG7zCO7zEW7zGe7zIm7zKu7zM27zOSybcBmbSO71d5gBo Sx8U8AGM2kg9u2RYQSRL/xadz2sRF7A84dWG3fcaD7AAHACxKYGBLvGdSHWoWvl/inEBNTQZBrBu Q+d+4ysRpBVfAsFHbmcqJtFRpQK/LfGdwiUiFRA9RWWsKOFzHBAcX/c8HfAiEuK+/zsQx8YTY6J0 VaEWGpofBaBul5oaeXp3BglCB/CeDkCpJOFzH2DBiUUAb8tgHQwRdaYWRCPCjMOqG6EbNtRIF7jC MiG/JVMB7vkBK2IyJHCNMLEXutNSyQUBGNBpSoMACgBrgNRIA9u87LuzVxcXsVYjB4CfCRABFtAB 9zQQcUoRM/IAXYg8SByZNZLHZnoWeRzGIwS1wOh0H3AB0WEm0YIz7LjDdf9EHRdAyJsGRhRithOB eQKheSnkfQC1WLpkVgmSACBQehqDOSgSsw7UUH6syGZTLQ2wkIpmHZH0WnecEAQDUkoFGwIDkhI1 TkDYUtSmUbk4ESFypfVYhKjcQk+SxltKMgzQAb+hybC8GhqgHhvgpBowa9b5mLncwo3UUQjgVAVD HjIMFVp1nVdzysUsH4+CGvPYEMykIOUhNgqsRfgJAOCqVGwhpWS3ygspv1BBNmgSFjm1oBqqH4eH HrVFv+dcE53iAEdKLknDOimsEPE8EB5mAceSNC6yv5l5AWZLADtpEPycH/uxxjaCI77EhJhRYrVy NSWc0C5hyAh2NeByALj/pB2xnIHajBF1KClS4iAaui09kV1V0dIuXRIFIGObtgCVeB8XMdEqEdIa gRkHIAEYNSUricU/JsFFPRLfZYDE1ooFMB4Q4MwW4dQpAdUdEQCSiDrQZznCEdYcAFxbbRLBgSL+ dCjIlzOHatYogdYkYSb/jE4MLX8V0SRZwkkfPddOAhq0F5SQkgDwNK8Swdcn4deF2yG8yEsNIo3R 0ZclhNDJq1V3zRBmshvRdxKUbRKWTasklAFtrU57eEDuhL8gqNiNBH1OilQFYDC5PRJ7U5/AHdzC /Z6/GR9PooltTKMbkXoVA9qyWzde0Y4lk5BiRNbTJysFhXw+cSXhjN0w/yUhy6e8dTOR0gEBNHIB 5F23M9Y5a1SPHbjGRbIADnVAEAU8cUEdhL27efFJo+YkkOIYIWDOK8FKvNG3prI1c6RotaYkOPIA eSV9V5Nao0Y2gui673h/TjJZEqfVNNEAbNwaxU0QDfBTzk071PF8E2Bovtx+EIgB/U25/igBLpaO 1vuMJV4SuhehG2CKUKFi4fxGao0ZGGABGEXHtNsARNMjRq6veAEaGbCgAk4T5fQ9gXkQ+5vMCUEj iQ3kDdyBBmZohhgSQGaUZF7mZn7maJ7mao7mF3C9LVQAzKMujWyhpA0uJRbeG+JUs8ZKb1I3GcVY 6T1eivbea0x2ESWe2f/pEtvpNdDjnhuQKivowH914y+RX8+EFnJdch2COukXf3mFiYneEotuNJ1i pwogATvGNt81HlvOHLHzXZNLciVzAdHjxhH1ywcR6iwx6kXDSkT0AE6aF64de6tChhiwNolKj3ID UdbmG5pqELq+Erw+QCmGP2IW5ZqRF3/qO3SXnl3uNhmQFD3I4Sox7RLRAQdgjuq+7uxejjrLITNS YvP9nB4WxwyzAOR+chBV5RMBSxbwjd5qlt4o2QRh7hHRnTDxnVdj3unX6kHSADWjEBjqXU9O6QQX 7QOBrBqwRxIgogoBmcSFKTcdvzntHBNQ04GjF6ybQiLbuhhPa0R1Wk7/TNG8IlEGDxEIj9NZI21/ 9X5JXD5c0i/Mgxy5Q9UWn00qkh/bfhD7wzxcgjzMEy10Yj5ErUwv32hHVS6eM5Utso5KtlM3/xA5 T/KR6yO7EtEzoZYEcS3ZQhcodK8HNDEMoTWn4TEM0LUKlZcEgXDPLC8DobkXn+9Y704OUDbcNBZE LBFh7xBjXxCTpXh8SjdYXpa7xNBoT17UYisZsIVUcioZMBbfweGnqUgmo7T22qWrxS6yXPjPs/lC nWKCn0yIlu+HQSEE4VTqtPkZsIaL3xCNr0XJlUfH0i9/6y23YVTXmRVqTzcAEixtORCT6JccIVP1 FYt6DxUDwAHZsc4A/1Av0R/7dfQkVwf+JdH7DPH7BDGcwu87xY8k2UxrSnX0R5j5ALCFynW9mVKG jbQBwXFqmwYQFx4AIFjQIEECGCgIONjwQoUBDSVKNOCBIYAKCQAw4FBwwsALBwpuQEAQAoOJKVWu ZNnS5UuYMWVOFLAAA0MJKGfu3AlBAs+WHAbuXMBhAAQPCy4WFKCAQMEGBSgULGCg5QALBQNEjaAT 6NeUAgaMJfsUQACyARCSHas25gCFSyUGgICh5EoDCMzKRMt2wFOxbC8GjgjW8GHEicFGvWCVYE7F kQH4lFxQKM8FEwpKgHCwqVkDCxIUSOsSa0MBEC4kuFvZdWICciUSoP8QYe9r3Ll1706MQGqDg5B5 9/zp+vLMBhWEA0ggsKQACgoKLCVQGOZpmgUihHA83HtDAp1ZIkgwVaWACxm6f2ff3v1M8hRub/b6 fiVl40Ptr8Su0kCECCBwa7/XAmBAA/FUEs06mlYbkEAII/QuAAQyeODBgzigwAAOO/TwQxBDFHFE Ej9coLjKjpOwof5WojAC9VZULAACMJQog4Vk1HHH9h7IIMGwBBBySCKLNPJIJJNUEsnXVOSxxZYI YMCBC+bj8SUhW0IAgwFsNMiAAgq4ckwyY4Lugi7LhNDJHQfwoIMDKoiggAcg0GulqBJ4wEo1DSLA gQiAO4+CDPg0qIH/0bzsc9Erz0RA0fAYZDQ/MgfY4IENFNBUUws0agmC5h6dtCAGBpCtIUQvGHVV VgsygAIH1mvogQqmazVF/Z7MioIPNu2gNZcMxMDWRRWdtQJBw9rwVmYJbOACB5p9b4IPLLD2Wmyz 1XZbbrv1NtsPiivAgg8uOPUlAhY44IFzV2ygAwqMJQi9BNolCC0OBJR2X+8GSECplAzIoF5+C+Zp gGQpdOBHeRtCq4AE6lsRTCAn8vdClmIzeGPXHriAAUPPgsABSTk2WSYCGmiYpgdGS5ZRCljDC9iT a+YpgJYhaDeAlW32mSUIIlgg5IkIKAADkO0LYIGuWBKgghxTCoDQ/4p/tvo8Biqg2SADD6jyarBj QsABe8/LQGv3AH15IgQ4kPWsBvZKueewbYbOAaIBaMDUuvuOKd21nR4AwMAJpI3s2TJQwAK0/Xbc gNHeZmoAyR23fCK0Lrhga5ZCG61swwSIeGV/zZOoAQs29YCDCDi/nGPyQKgcADArwPh13F8ygG6o IkhAZ8kMoJKlpRMo2SAINl3c68Jzlxat8kDn2XnqiS8qgdlTGrkAlb8TYE6iCbjAAwscaL56ZukS Gn32DePdYR9V5a0BDKqWCPT2WYXV/vz73y2A0GSAAe/ji3ay57+NBUBzokJgA79DF82lSTHiKwAB Hbgq8V3gfNCpwP8CLHhB9lXngKjJgAQOcEIUplCFK2RhC134whVaYIQbI4AF4ARDHOZQhy7UQLTm whXQQQACeQMhCOtiPpjIiUwB2MD5TkYAp5ApARiQCAIcFBb+SaZGReyfEsfERCeaDIpE3M8UDzI4 D6akAQ6YgOtWIoEPfGABBhFAHO3oKfpwsW7Q6cDXUuLFK4GxbmOUIhUJkjPpbXEny5mXAt5GgHVZ QGJ6bA8EOmABMSEvAQDynVpaNoEMAIUuRAMkjwQZNkKOaYonEI2+JsKAzRmGkQBoipx81xnsCIcA D8gkJb9DgQ40hALygcADOjCgBITSTx9M1+YeVMqY0EWI01wbAoT/OEOpXQoB2+RmN735TXCGU5zj JGc5zcmAKMJnmtOcy/FikoBOAYsAiiRIRrDJkllOxi0OcAAEfiTETqUMYr305XCA6R8FLCWZWoFY GP1TAPnVMwKi9ECyCiCSx9zFjDth4gL88lGQhlSkIyVpSU060gekcyaADEBFDfIAD3xAai7ZKFMw sIEK3BMmAZAAuwRQgGAKoIlCAhTXeuoq0xWUNwc9yGoIYoCEFmSh81qNQ5M40Zu5lCAXbcgm+XQS 4jVxkCqVCUu1CoCLIkCm98PjSmpKkAj0SgEbOMAH/fOhvXRINh2yq1LB8gANfAADg/VARMgz2Ayk 8QIYkIAFMIBV/9rh76oUvcACNHCArQ1ANFPBGcEmM0mHiRWVZI1JBTqwAAd8QD8xK4laC+Ib8YiO poYkCAMkoDwFfKCCfuUtYqAZTa1GoAITmaIAWqYnBjBghqeUGj2llcqVYrUBHnDLAipw3QN4oAIP K09y3SmRmhIgsBw4gAMKMMTeptcwv30JXTxwOx9tEwDdTAAeAdZe0R4EgOraQAe+i0HS6u4AMTrL BBiAgKW4tiADcGNKwttX9UZYIuxdEXNpaVnccuC8fykIAax5p7VAoAFLMcBRuge3a0J4J9Dl0Vsl /OL1QtaU+aXlAFKrPA0soAEG2IsADLBjuf3YACQWslsA+GNFCv+gAdvsjpKZ3OFtxs1VUd7LkhFw YgCweEcuhnGXd0JhCVn4Sw9wAHn/Oyot64jLXmbzS8AcITFjrmBpltGa23xnlbwZQnH2GZ1XZGc8 B/ogeiYQn23mZwkBWtCLroAFJvBoSEda0pOmdKUtfelJn/VqBPCABjD9aVCH+tISUOaiTa3eBJDx 1KtmtYwQMAEFdOBUOPPAXZ51QgzcrtW75vV+ELABhx0IACQhCLRohDpV91rZy0bMr2elAYIQWysp s8BTGPA7Zmdb270B9pdCcoAOKKCNAODlvDzA45hlcdvrZnfAKuCB+iZAAhEVnXatErR4R+AiHGp3 v/39b4AHXOAUAyd4wQ1+cIQnXOELZ3jDHd7qgAAAOw== --_004_140620498661196069junipernet_-- From nobody Thu Jul 24 05:35:58 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93C41A02D1 for ; Thu, 24 Jul 2014 05:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os3FIOJiFb2z for ; Thu, 24 Jul 2014 05:35:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1699E1A0280 for ; Thu, 24 Jul 2014 05:35:54 -0700 (PDT) Received: from hannes-mba.local (66.129.239.10) by BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 24 Jul 2014 12:35:52 +0000 Message-ID: <53D0FDA1.1070701@juniper.net> Date: Thu, 24 Jul 2014 14:35:45 +0200 From: Hannes Gredler Organization: Juniper Networks, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Subject: On minimizing SPF backoff induced blackouts Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.239.10] X-ClientProxiedBy: BY2PR04CA055.namprd04.prod.outlook.com (10.141.249.173) To BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 028256169F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(199002)(189002)(31966008)(105586002)(95666004)(101416001)(86362001)(102836001)(46102001)(80022001)(64706001)(65956001)(81542001)(20776003)(81342001)(47776003)(229853001)(42186005)(106356001)(4396001)(2351001)(64126003)(107046002)(19580395003)(74662001)(74502001)(54356999)(83072002)(50986999)(65816999)(83322001)(85852003)(92726001)(77096002)(50466002)(23676002)(59896001)(107886001)(33656002)(36756003)(85306003)(66066001)(65806001)(99396002)(83506001)(110136001)(15975445006)(79102001)(92566001)(21056001)(76482001)(77982001)(87976001)(80316001)(87266999); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB433; H:hannes-mba.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/VpO5TeUyq7F0lIISuyJfQ3nisFM X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 12:35:58 -0000 hi RTGWG, some old presentation from Dave Katz on backoff and timing. https://www.nanog.org/meetings/nanog25/presentations/katz.ppt [courtesy Chris Bowers for digging it up ...] slide 15 is of particular interest - says that if an implementation and the system around it is properly designed then no backoff should be required. /hannes From nobody Thu Jul 24 09:56:54 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4B91A0538 for ; Thu, 24 Jul 2014 09:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUO-LasBwcwh for ; Thu, 24 Jul 2014 09:56:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BCF1A04B8 for ; Thu, 24 Jul 2014 09:56:48 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id DFDD01B9606; Thu, 24 Jul 2014 18:56:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id C08B23840D3; Thu, 24 Jul 2014 18:56:46 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.91]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 18:56:46 +0200 From: To: Uma Chunduri , DECRAENE Bruno IMT/OLN , "rtgwg@ietf.org" Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt Thread-Topic: draft-decraene-rtgwg-backoff-algo-00.txt Thread-Index: Ac+Wp+MyvMnaa2ToRgGqZeRoKdO52QQCcvZwAA0uvsAAHk6eIA== Date: Thu, 24 Jul 2014 16:56:45 +0000 Message-ID: <23003_1406221006_53D13ACE_23003_13379_1_655e13bb-a6d5-4741-a12f-98f417d8669f@OPEXCLILH05.corporate.adroot.infra.ftgroup> References: <31904_1404383234_53B53002_31904_1678_1_53C29892C857584299CBF5D05346208A07177B15@PEXCVZYM11.corporate.adroot.infra.ftgroup> <17448_1406147099_53D01A1B_17448_6400_1_53C29892C857584299CBF5D05346208A0718F675@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A60469152008633F314853@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F314853@eusaamb105.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.102419 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/OB-KA9hsmAp2DYNGChj0FxKtJWo X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:56:51 -0000 Hi Uma, Thanks for the comment and your support. Pls find inline comments. -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: Wednesday, July 23, 2014 22:43 To: DECRAENE Bruno IMT/OLN; rtgwg@ietf.org Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt Dear Bruno, Stephane, > my understanding is that all commenters agreed that having a=20 > standardized algorithm would be better as it would allow all routers=20 > in a network to compute the same SPF delay Sure, It's fine to have a uniform mandatory SPF trigger algorithm. But I would note the for the link failure examples described in https://d= atatracker.ietf.org/doc/draft-litkowski-rtgwg-spf-uloop-pb-statement/?inclu= de_text=3D1 (Section 2) we have LFA's which can serve us till the re-conve= rgence happens. [SLI] No , unfortunately LFA (nor RSVP-TE link protect for monohop tunnels)= would help in this ... As soon as S converges, S would stop using LFA and = may fall into a loop to E. Also : In Section 3 you said - =3D=3D=3D=3D 2. Run only Full SPF when required : e.g. if a link fails, a local node will run an SPF for its local LSP update. If the LSP from the neighbor (describing the same failure) is received after SPF has started, the local node can decide that a new full SPF is not required as the topology has not change. 3. If topology does not change, only recompute reachability. =3D=3D=3D=3D As we all agree it's very cheap to compute SPF (especially when we are doin= g 100's LFA/remote LFA SPFs for each primary SPF) today; in that context we= should not be picky on primary SPF (Partial/Full).=20 Just to give an example, due to multi-homed prefixes in the network, if we= do incorrect computation to save few mill-seconds this can last till the n= ext trigger comes! So I would request to avoid above discussion in this context, as that is no= t the main point of the draft/what you are seeking. [SLI] That was not my point ... we have an agreement that SPF is cheap. But= the issue may come from timer management and when to trigger SPF. If imple= mentations are using different strategies, they will be misaligned in term = of delay timer values for a particular sequence of event. SPF duration is n= ot involved there ...=20 -- Uma C. -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of bruno.decraene@ora= nge.com Sent: Wednesday, July 23, 2014 4:25 PM To: rtgwg@ietf.org Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt Hi all, Today's presentations have triggered many interesting feedback and comment = (which is good, many thanks for your time) but time has not allowed discuss= ing all the comments (a) nor summarizing the feedbacks (b). Regarding a), could you please post your additional comments on the list? (= or emailed them privately if preferred) As all comments are welcomed. Regarding b), my understanding is that all commenters agreed that having a = standardized algorithm would be better as it would allow all routers in a n= etwork to compute the same SPF delay (*). Please correct me if I'm wrong. Thanks, Regards, Bruno, St=E9phane (*) assuming that the network owner has configured the same parameters on a= ll routers; but this is orthogonal. > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of >=20 > Hi all, >=20 > Please find below a proposed short draft which: > -a- calls for a standardized SPF back-off algorithm, for=20 > interoperability purpose > -b- proposes an algorithm >=20 > Comments are welcomed. >=20 > Note that v00 currently proposes the algorithm which is the most=20 > deployed. I would be fine with any modification, based on WG consensus=20 > (assuming WG adoption). >=20 > Thanks, > Regards, > Bruno > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, July 03, 2014 12:16 PM >=20 > A new version of I-D, draft-decraene-rtgwg-backoff-algo-00.txt > has been successfully submitted by Bruno Decraene and posted to the=20 > IETF repository. >=20 > Name: draft-decraene-rtgwg-backoff-algo > Revision: 00 > Title: Back-off SPF algorithm for link state IGP > Document date: 2014-07-03 > Group: Individual Submission > Pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-decraene-rtgwg- > backoff-algo-00.txt > Status: https://datatracker.ietf.org/doc/draft-decraene-rtgwg-bac= koff- > algo/ > Htmlized: http://tools.ietf.org/html/draft-decraene-rtgwg-backoff-a= lgo- > 00 >=20 >=20 > Abstract: > This document defines a standard algorithm to back-off link-state IGP > SPF computations. >=20 > This improves interoperability by reducing the probability and/or > duration of transient forwarding loops during the IGP convergence in > the area/level when the network reacts to multiple consecutive > events. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 24 09:59:13 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20EF1A0538 for ; Thu, 24 Jul 2014 09:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR1RJ7-2UUIQ for ; Thu, 24 Jul 2014 09:59:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A32F1A04B8 for ; Thu, 24 Jul 2014 09:59:08 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5641C22E8CF; Thu, 24 Jul 2014 18:59:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 397D72380EB; Thu, 24 Jul 2014 18:59:06 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.91]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 18:59:05 +0200 From: To: Hannes Gredler , "rtgwg@ietf.org" Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQHPpzvUfDZOmpkuSUWGoaZndaas2puvcjKw Date: Thu, 24 Jul 2014 16:59:05 +0000 Message-ID: <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <53D0FDA1.1070701@juniper.net> In-Reply-To: <53D0FDA1.1070701@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.121217 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/v0k9kPEvBv6-kfHTbnL8tyMvbB4 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:59:11 -0000 Hannes, " if an implementation and the system around it is properly designed" -> This is exactly what SP are trying to be protected against (bad implemen= tations) :) Can every vendor sign with blood that their implementation and system are p= roperly designed for all situations ... unfortunately (for us) I don't thin= k so :) Stephane -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Hannes Gredler Sent: Thursday, July 24, 2014 08:36 To: rtgwg@ietf.org Subject: On minimizing SPF backoff induced blackouts hi RTGWG, some old presentation from Dave Katz on backoff and timing. https://www.nanog.org/meetings/nanog25/presentations/katz.ppt [courtesy Chris Bowers for digging it up ...] slide 15 is of particular interest - says that if an implementation and the= system around it is properly designed then no backoff should be required. /hannes _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 24 10:39:41 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDB21A8BB5 for ; Thu, 24 Jul 2014 10:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csqow4y0FzO5 for ; Thu, 24 Jul 2014 10:39:34 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E83C1ABD18 for ; Thu, 24 Jul 2014 10:39:34 -0700 (PDT) Received: from dhcp-9565.meeting.ietf.org ([31.133.149.101]:54044 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1XAMzM-0003kY-1v; Thu, 24 Jul 2014 17:39:32 +0000 From: "Russ White" To: , "'Hannes Gredler'" , References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> Subject: RE: On minimizing SPF backoff induced blackouts Date: Thu, 24 Jul 2014 13:39:28 -0400 Message-ID: <05b501cfa766$38872f00$a9958d00$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKfOg5XlMNKpCA7puSG3VrQ8sU3kwGag2g9mgOEGeA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/beanZmio6DAGhL791z_kGlda7cI X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:39:38 -0000 > Can every vendor sign with blood that their implementation and system are > properly designed for all situations ... unfortunately (for us) I don't think so :) Which is why this would be a good BCP -- both for vendors and providers. :-) Russ From nobody Thu Jul 24 10:40:31 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF94C1ACAD6 for ; Thu, 24 Jul 2014 10:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrQsstNNUGfU for ; Thu, 24 Jul 2014 10:40:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D1E1ABB23 for ; Thu, 24 Jul 2014 10:40:24 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 30D8F22E557; Thu, 24 Jul 2014 19:40:23 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 163F04C06D; Thu, 24 Jul 2014 19:40:23 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 19:40:23 +0200 From: To: Hannes Gredler , "rtgwg@ietf.org" Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQHPpzvUkBjwg44kXk2vtA6Yw1s9a5uvdNLA Date: Thu, 24 Jul 2014 17:40:22 +0000 Message-ID: <7798_1406223623_53D14507_7798_3927_1_53C29892C857584299CBF5D05346208A0718FC7C@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <53D0FDA1.1070701@juniper.net> In-Reply-To: <53D0FDA1.1070701@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.121217 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/Ro0FatSND3FMCAcXCNWAr2G_Flk X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:40:28 -0000 Hi Hannes, Many thanks for the slides: quite interesting and to the point. Very useful. More inline. > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Hannes Gredler >=20 > hi RTGWG, >=20 > some old presentation from Dave Katz on backoff and timing. > https://www.nanog.org/meetings/nanog25/presentations/katz.ppt > [courtesy Chris Bowers for digging it up ...] >=20 > slide 15 is of particular interest - says that if an implementation and t= he > system around it is properly designed then no backoff should be required. - so why did this particular implementation included a SPF backoff algorith= m? ;-) - I will not comment about "properly designed" but (probably) all systems h= ave bugs and/or sub-optimal design parts - Sorry, but I would argue that if existing SPF backoff algorithm were "pro= perly designed", they would be standardized to allow for inter-vendor consi= stency - If after 10 consecutive SPFs runs in 1 second, the IGP still haven't solv= ed the problem, then keep doing the same thing again and again may not help= , at least urgency will probably not help/be needed. Eventually the IGP SPF= is part of the problem e.g. by creating system & network churn, micro-loop= s... IMHO, trying to calm down the IGP reaction seems a valid option to try= . At least this reduces the number of micro-loops in the network. - slide 15 seems to only consider intra-system impacts (looks even intra-IG= P only). From a network wide perspective, the more SPF/FIB change, the more= micro-loops.=20 Bruno >=20 > /hannes >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 24 10:53:58 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B1D1A0AAC for ; Thu, 24 Jul 2014 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ0rjGfaACFl for ; Thu, 24 Jul 2014 10:53:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CCA1ACCF3 for ; Thu, 24 Jul 2014 10:53:08 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id CB0EC3262D3; Thu, 24 Jul 2014 19:53:06 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B136F27C054; Thu, 24 Jul 2014 19:53:06 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 19:53:06 +0200 From: To: Russ White , "rtgwg@ietf.org" Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQKfOg5XkBjwg44kXk2vtA6Yw1s9awGag2g9mgOEGeCAAACvYA== Date: Thu, 24 Jul 2014 17:53:05 +0000 Message-ID: <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> In-Reply-To: <05b501cfa766$38872f00$a9958d00$@riw.us> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.121217 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/6ij35utbho_gXLDQbd1g1_7H_TA X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:53:46 -0000 Russ, > > Can every vendor sign with blood that their implementation and system > > are properly designed for all situations ... unfortunately (for us) I > > don't think so :) >=20 > Which is why this would be a good BCP -- both for vendors and providers. I'm not sure to exactly see your point. So let me expand into more details: We don't need consistency between different AS/providers. We need consistency within a given AS, across vendors. BCP for existing _parameters_ do not solve the problem if we have different= algorithm computing different values. What we need is to standardize an algorithm. Is your point is that such doc= ument should be labeled as "IETF BCP" rather than "IETF standard track"? If= so, I would tend to disagree as IMO this is required for interop. Thanks, Bruno >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 24 11:01:14 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9F11A019C for ; Thu, 24 Jul 2014 11:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihEAAuRxrPhd for ; Thu, 24 Jul 2014 11:01:05 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36121A03C4 for ; Thu, 24 Jul 2014 11:01:04 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-ca-53d0f6d8ab37 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.2B.05330.8D6F0D35; Thu, 24 Jul 2014 14:06:49 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 14:01:03 -0400 From: Uma Chunduri To: "stephane.litkowski@orange.com" , "DECRAENE Bruno IMT/OLN" , "rtgwg@ietf.org" Subject: RE: draft-decraene-rtgwg-backoff-algo-00.txt Thread-Topic: draft-decraene-rtgwg-backoff-algo-00.txt Thread-Index: Ac+Wp+MyvMnaa2ToRgGqZeRoKdO52QQCcvZwAA0uvsAAHk6eIAACOzmg Date: Thu, 24 Jul 2014 18:01:02 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F314F9A@eusaamb105.ericsson.se> References: <31904_1404383234_53B53002_31904_1678_1_53C29892C857584299CBF5D05346208A07177B15@PEXCVZYM11.corporate.adroot.infra.ftgroup> <17448_1406147099_53D01A1B_17448_6400_1_53C29892C857584299CBF5D05346208A0718F675@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A60469152008633F314853@eusaamb105.ericsson.se> <23003_1406221006_53D13ACE_23003_13379_1_655e13bb-a6d5-4741-a12f-98f417d8669f@OPEXCLILH05.corporate.adroot.infra.ftgroup> In-Reply-To: <23003_1406221006_53D13ACE_23003_13379_1_655e13bb-a6d5-4741-a12f-98f417d8669f@OPEXCLILH05.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPrO7NbxeCDS5dYbf4sWMOs8WFN7+Z Lb7ufcjqwOyxZMlPJo+WZyfZApiiuGxSUnMyy1KL9O0SuDIez9vEXnCBteLylnesDYzHWLoY OTgkBEwk9hyx6WLkBDLFJC7cW8/WxcjFISRwlFHi3tN9zBDOckaJ/htT2EGq2AT0JD5O/ckO khARWMAo8fntEzaQhLCAqcSX1lPMILaIgJnEnhX/mCBsN4mtl9aBxVkEVCXObJ4EZvMK+Eq8 bbkMteEos8Shx3NYQBxOgTZGiY0rJ4N1MwId9f3UGjCbWUBc4taT+UwQxwpILNlznhnCFpV4 +fgfK4StJPHx93x2iHodiQW7P7FB2NoSyxa+htosKHFy5hOWCYyis5CMnYWkZRaSlllIWhYw sqxi5CgtTi3LTTcy2MQIjI5jEmy6Oxj3vLQ8xCjAwajEw7ug/XywEGtiWXFl7iFGaQ4WJXHe WbXzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwRgg+Mq+91ForG7dT4Pe3jG/vZnGrhARI npsn4O6i0zJrZXW11E2Fk18fekpPvZFi+Slbd+1ytz1rXnre9J26cIv7BzuHlyKHJuZX16fe TbsktG+Wc8ZiA7uypxWRud2qy29VH9x6LqaJ2fXcm4lhR/2eOl6wsVSw/81uwrnp1n0rlS6e 3OeFSizFGYmGWsxFxYkAzwCUvm8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/5l7jz5ZWl6H1IyhoaQCz1FyABM8 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:01:11 -0000 Hi Stephane, >> But I would note the for the link failure examples described in https:= //datatracker.ietf.org/doc/draft-litkowski-rtgwg-spf-uloop-pb-statement/?in= clude_text=3D1 (Section 2) we have LFA's which can serve us till the re-co= nvergence happens. >[SLI] No , unfortunately LFA (nor RSVP-TE link protect for monohop tunnels= ) would help in this ... As soon as S converges, S would stop using LFA and= may fall into a loop to E. Then I am afraid even with same trigger logic and timers across all vendors= , you may still see the micro loops.=20 Various mitigation techniques for that issue is listed elaborately here - http://tools.ietf.org/html/rfc5715#section-6 -- Uma C. From nobody Thu Jul 24 11:02:49 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA7A1A0496 for ; Thu, 24 Jul 2014 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfGR4xSQhTau for ; Thu, 24 Jul 2014 11:02:38 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B881A028E for ; Thu, 24 Jul 2014 11:02:29 -0700 (PDT) Received: from dhcp-9565.meeting.ietf.org ([31.133.149.101]:54169 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1XANLX-0003xO-PT; Thu, 24 Jul 2014 18:02:27 +0000 From: "Russ White" To: , References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> Subject: RE: On minimizing SPF backoff induced blackouts Date: Thu, 24 Jul 2014 14:02:21 -0400 Message-ID: <061001cfa769$6c85b3a0$45911ae0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKfOg5XlMNKpCA7puSG3VrQ8sU3kwGag2g9AoUT398CfNrLYZnbeLTg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/IR1UHMI93IZhVU4Rc17BCdnGAOQ X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:02:45 -0000 > We don't need consistency between different AS/providers. > We need consistency within a given AS, across vendors. Correct -- but a BCP isn't just for inter-AS, it's also for intervendor. > BCP for existing _parameters_ do not solve the problem if we have different > algorithm computing different values. > What we need is to standardize an algorithm. Is your point is that such > document should be labeled as "IETF BCP" rather than "IETF standard track"? > If so, I would tend to disagree as IMO this is required for interop. The problem is with the word "interop." Typically, algorithms have only been specified to the point that all instances of a given routing protocol are eventually consistent (how the best path is calculated, which events should or should not trigger updates, etc.) -- what you're asking is for this to be extended to timing and the actual process used in specific situations. This would analogous to asking for a spec around the actual way in which BGP tables are stored (rather than the theoretical model proposed in the BGP specs). I see a couple of problems with going down this path -- the most prominent of which is that it kills off the ability to think of better ways to implement the functionality under discussion. Given all of this, the problem we have is that different implementations back off in different ways, which causes microloops and microblackholes. If we set upper and lower bounds on the time to react in each given situation, then we're solving that problem without telling people how to get to those upper and lower bounds. If we propose an actual algorithm, then we're telling people not only what must happen, but how it must happen. I suspect we're crossing a line in there someplace that reaches outside the IETF's scope. Hence, I would argue for a BCP that says, "this is what must happen and when," which would be similar to telling BGP implementors the way dampening should look from another implementation's point of view... The implementation is still (pretty much) a block box. I don't know if we should slip over the line into telling people how to implement. I'm willing to be persuaded, I just don't see the argument for specifying an algorithm with what's been put on the table to this point. :-) Russ From nobody Thu Jul 24 11:49:28 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839E11A0146 for ; Thu, 24 Jul 2014 11:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw2ziSDrq6Z1 for ; Thu, 24 Jul 2014 11:49:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC191A0417 for ; Thu, 24 Jul 2014 11:49:24 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 833172ADD5C; Thu, 24 Jul 2014 20:49:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6AFB8384049; Thu, 24 Jul 2014 20:49:22 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 20:49:22 +0200 From: To: Russ White Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQKfOg5XlMNKpCA7puSG3VrQ8sU3kwGag2g9AoUT398CfNrLYZnbeLTggAAJ5aA= Date: Thu, 24 Jul 2014 18:49:20 +0000 Message-ID: <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <061001cfa769$6c85b3a0$45911ae0$@riw.us> In-Reply-To: <061001cfa769$6c85b3a0$45911ae0$@riw.us> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.181220 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/BH_ebV6yVKj9kqn2-G2myRIIg6o Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:49:26 -0000 > > We don't need consistency between different AS/providers. > > We need consistency within a given AS, across vendors. >=20 > Correct -- but a BCP isn't just for inter-AS, it's also for intervendor. Good. #Ref A >=20 > > BCP for existing _parameters_ do not solve the problem if we have > different > > algorithm computing different values. > > What we need is to standardize an algorithm. Is your point is that > > such document should be labeled as "IETF BCP" rather than "IETF > > standard > track"? > > If so, I would tend to disagree as IMO this is required for interop. >=20 > The problem is with the word "interop." Typically, algorithms have only b= een > specified to the point that all instances of a given routing protocol are > eventually consistent (how the best path is calculated, which events shou= ld > or should not trigger updates, etc.) we also need consistency, between nodes in a given AS, on the delay before = running the SPF. We agreed on this. cf above #Ref A > -- what you're asking is for this to be > extended to timing and the actual process used in specific situations. Th= is > would analogous to asking for a spec around the actual way in which BGP > tables are stored (rather than the theoretical model proposed in the BGP > specs). I disagree with your analogy. IMO, the BGP analogy is, within an AS, following an internal route change, = to trigger BGP route re-computation at the same time across vendors. e.g. a= gree on the mechanism (e.g. BGP scan time vs triggered computation). (but it's still a bit different as for BGP you could use tunnels between AS= BR to avoid hitting RIB inconsistencies) > I see a couple of problems with going down this path -- the most > prominent of which is that it kills off the ability to think of better wa= ys to > implement the functionality under discussion. I disagree. cf slide 7 http://tools.ietf.org/agenda/90/slides/slides-90-rtg= wg-2.pdf > Given all of this, the problem we have is that different implementations = back > off in different ways, which causes microloops and microblackholes. +1 > If we set > upper and lower bounds on the time to react in each given situation, then > we're solving that problem without telling people how to get to those upp= er > and lower bounds. If we propose an actual algorithm, then we're telling > people not only what must happen, but how it must happen. I suspect we're > crossing a line in there someplace that reaches outside the IETF's scope. We need "close"/identical values, across all nodes, for _all_ the steps of = the back-off algorithm/spec. From the first event of the set of consecutive= events, up to the last events. If we have a 2 steps back-off algorithm (fast - slow) I guess setting the u= pper and lower bound is enough. But this assumes that we all agree on this = 2 steps mechanism/algo. (while we/vendors don't today) We also need to define how we determine this set of consecutive events. And= make sure we are consistent about which are those events (e.g. refresh LSA= /LSP are not). =20 > Hence, I would argue for a BCP that says, "this is what must happen and > when," which would be similar to telling BGP implementors the way > dampening should look from another implementation's point of view... The > implementation is still (pretty much) a block box. I don't know if we sho= uld > slip over the line into telling people how to implement. >=20 > I'm willing to be persuaded, I just don't see the argument for specifying= an > algorithm with what's been put on the table to this point. Ok. So I guess my presentation/draft was not clear enough.=20 Can we try to sync face to face during this week? Thanks, Bruno >=20 > :-) >=20 > Russ ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 24 11:56:47 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2740B1A005F for ; Thu, 24 Jul 2014 11:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHIEiPdpPS5Z for ; Thu, 24 Jul 2014 11:56:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE191A002A for ; Thu, 24 Jul 2014 11:56:42 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 798AE3B5981; Thu, 24 Jul 2014 20:56:41 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6105938404E; Thu, 24 Jul 2014 20:56:38 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 20:56:38 +0200 From: To: Russ White Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQKfOg5XlMNKpCA7puSG3VrQ8sU3kwGag2g9AoUT398CfNrLYZnbeLTggAAJ5aCAAAbLUA== Date: Thu, 24 Jul 2014 18:56:37 +0000 Message-ID: <23003_1406228198_53D156E6_23003_17158_1_53C29892C857584299CBF5D05346208A0718FDB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <061001cfa769$6c85b3a0$45911ae0$@riw.us> <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.181220 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/OzdqO0kMwIlIFkrjFguYzzl2wYQ Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:56:45 -0000 > > I'm willing to be persuaded, I just don't see the argument for > > specifying an algorithm with what's been put on the table to this point. >=20 > Ok. So I guess my presentation/draft was not clear enough. Let me try again. In slide 5: http://tools.ietf.org/agenda/90/slides/slides-90-rtgwg-2.pdf - do we agree that it would be better if node A and B both schedule their S= PF at roughly the same time? i.e. wait for the same duration? - if so, what would be your proposition? Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 24 12:03:27 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66B1A0146 for ; Thu, 24 Jul 2014 12:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiLw3epsTW33 for ; Thu, 24 Jul 2014 12:03:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E151A002A for ; Thu, 24 Jul 2014 12:03:23 -0700 (PDT) Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 19:03:20 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([169.254.12.69]) by CO1PR05MB443.namprd05.prod.outlook.com ([169.254.12.69]) with mapi id 15.00.0990.007; Thu, 24 Jul 2014 19:03:20 +0000 From: Hannes Gredler To: "bruno.decraene@orange.com" , Russ White Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQHPpzvPRnPPJaE1WUagHjrksWeNdZuvcq+AgAALSACAAAPOgIAAApeAgAANIQCAAAIIgIAAAFOY Date: Thu, 24 Jul 2014 19:03:19 +0000 Message-ID: <1406228599846.53663@juniper.net> References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <061001cfa769$6c85b3a0$45911ae0$@riw.us> <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup>, <23003_1406228198_53D156E6_23003_17158_1_53C29892C857584299CBF5D05346208A0718FDB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <23003_1406228198_53D156E6_23003_17158_1_53C29892C857584299CBF5D05346208A0718FDB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:144:1857:bba9:732f:7c3e] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(199002)(189002)(21056001)(99286002)(54356999)(4396001)(46102001)(77982001)(87936001)(15202345003)(85306003)(81342001)(106116001)(107046002)(83072002)(76482001)(92726001)(81542001)(105586002)(74502001)(83322001)(99396002)(15975445006)(95666004)(64706001)(36756003)(79102001)(80022001)(76176999)(19580405001)(74662001)(31966008)(20776003)(19580395003)(92566001)(106356001)(77096002)(93886003)(2656002)(86362001)(101416001)(85852003)(50986999)(3826002)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB443.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/5SVs7bAVkm4aDI4n_1FYsM0gytE Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:03:25 -0000 hi bruno,=0A= =0A= IMO the problem that you're trying to solve is to have the routers=0A= still being responsive when multiple events are happening in the=0A= network.=0A= =0A= wouldn't then a simple fix be to kick the SPF pacing logic at a much more= =0A= later point in time ? - i.e. rather than slowing down things=0A= down on event #2 or #3, do it at event # (please insert you're=0A= favorite number for )=0A= =0A= /hannes=0A= =0A= ________________________________________=0A= From: rtgwg on behalf of bruno.decraene@orange.com= =0A= Sent: Thursday, July 24, 2014 20:56=0A= To: Russ White=0A= Cc: rtgwg@ietf.org=0A= Subject: RE: On minimizing SPF backoff induced blackouts=0A= =0A= > > I'm willing to be persuaded, I just don't see the argument for=0A= > > specifying an algorithm with what's been put on the table to this point= .=0A= >=0A= > Ok. So I guess my presentation/draft was not clear enough.=0A= =0A= Let me try again.=0A= In slide 5: http://tools.ietf.org/agenda/90/slides/slides-90-rtgwg-2.pdf=0A= - do we agree that it would be better if node A and B both schedule their S= PF at roughly the same time? i.e. wait for the same duration?=0A= - if so, what would be your proposition?=0A= =0A= Bruno=0A= =0A= =0A= ___________________________________________________________________________= ______________________________________________=0A= =0A= Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc=0A= pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler=0A= a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,=0A= Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.=0A= =0A= This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;=0A= they should not be distributed, used or copied without authorisation.=0A= If you have received this email in error, please notify the sender and dele= te this message and its attachments.=0A= As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.=0A= Thank you.=0A= =0A= _______________________________________________=0A= rtgwg mailing list=0A= rtgwg@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rtgwg=0A= From nobody Thu Jul 24 12:13:57 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263891A8BB0 for ; Thu, 24 Jul 2014 12:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOI05RrKb4wr for ; Thu, 24 Jul 2014 12:13:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52D51A002A for ; Thu, 24 Jul 2014 12:13:53 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C5CB82AE2FA; Thu, 24 Jul 2014 21:13:51 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id AB908384049; Thu, 24 Jul 2014 21:13:51 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 21:13:51 +0200 From: To: Hannes Gredler , Russ White Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQKfOg5XlMNKpCA7puSG3VrQ8sU3k5uvcq+AgAALSACAAAPOgIAAApeAgAANIQCAAAIIgIAAAFOY/mDdKWA= Date: Thu, 24 Jul 2014 19:13:50 +0000 Message-ID: <23003_1406229231_53D15AEF_23003_17543_1_53C29892C857584299CBF5D05346208A0718FDF0@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <061001cfa769$6c85b3a0$45911ae0$@riw.us> <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup>, <23003_1406228198_53D156E6_23003_17158_1_53C29892C857584299CBF5D05346208A0718FDB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1406228599846.53663@juniper.net> In-Reply-To: <1406228599846.53663@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.181220 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/dOm2XO0jiHsnzbslJNEG-KHUW0A Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:13:56 -0000 Hi Hannes, =20 > hi bruno, >=20 > IMO the problem that you're trying to solve is to have the routers still = being > responsive when multiple events are happening in the network. >=20 > wouldn't then a simple fix be to kick the SPF pacing logic at a much more= later > point in time ? - i.e. rather than slowing down things down on event #2 o= r #3, > do it at event # (please insert you're favorite number for ) IMO that's a valid option. Would work for me if the WG agrees on that one. (but there are many options= and different opinions, so next step is to build consensus on this) We'll try to propose something, with your proposition in mind. Thanks for your contribution. Bruno >=20 > /hannes >=20 > ________________________________________ > From: rtgwg on behalf of > bruno.decraene@orange.com > Sent: Thursday, July 24, 2014 20:56 > To: Russ White > Cc: rtgwg@ietf.org > Subject: RE: On minimizing SPF backoff induced blackouts >=20 > > > I'm willing to be persuaded, I just don't see the argument for > > > specifying an algorithm with what's been put on the table to this poi= nt. > > > > Ok. So I guess my presentation/draft was not clear enough. >=20 > Let me try again. > In slide 5: http://tools.ietf.org/agenda/90/slides/slides-90-rtgwg-2.pdf > - do we agree that it would be better if node A and B both schedule their= SPF > at roughly the same time? i.e. wait for the same duration? > - if so, what would be your proposition? >=20 > Bruno >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 24 12:49:19 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48711A0AB9 for ; Thu, 24 Jul 2014 12:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GV9aez6XzRG9 for ; Thu, 24 Jul 2014 12:49:13 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC45D1A02D6 for ; Thu, 24 Jul 2014 12:49:13 -0700 (PDT) Received: from dhcp-a0bf.meeting.ietf.org ([31.133.160.191]:61944) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XAP0p-0004lu-8l; Thu, 24 Jul 2014 19:49:12 +0000 References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <061001cfa769$6c85b3a0$45911ae0$@riw.us> <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup> Mime-Version: 1.0 (1.0) In-Reply-To: <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11D257) From: Russ White Subject: Re: On minimizing SPF backoff induced blackouts Date: Thu, 24 Jul 2014 15:49:07 -0400 To: "" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/BhPjUaC_jeMjYR7WsV6LgMuu9Nk Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:49:17 -0000 Replying from mobile, forgive the top post... :-( I was thinking of a bcp that would say something like: - these are the different points that matter in convergence timing - vendors are encouraged to provide timers between x and y for each of these= - vendors are further encouraged to use x, y, ... As defaults - operators are cautioned that this is the set of problems they will face if= these timers are not consistent - operators are encouraged to use consistent timers, rather than waiting on v= endors to use a common set of defaults Would that cover what needs to be done without specifying an actual algorith= m? :-) Russ On Jul 24, 2014, at 2:49 PM, wrote: >>> We don't need consistency between different AS/providers. >>> We need consistency within a given AS, across vendors. >>=20 >> Correct -- but a BCP isn't just for inter-AS, it's also for intervendor. >=20 > Good. > #Ref A >=20 >>=20 >>> BCP for existing _parameters_ do not solve the problem if we have >> different >>> algorithm computing different values. >>> What we need is to standardize an algorithm. Is your point is that >>> such document should be labeled as "IETF BCP" rather than "IETF >>> standard >> track"? >>> If so, I would tend to disagree as IMO this is required for interop. >>=20 >> The problem is with the word "interop." Typically, algorithms have only b= een >> specified to the point that all instances of a given routing protocol are= >> eventually consistent (how the best path is calculated, which events shou= ld >> or should not trigger updates, etc.) >=20 > we also need consistency, between nodes in a given AS, on the delay before= running the SPF. > We agreed on this. cf above #Ref A >=20 >> -- what you're asking is for this to be >> extended to timing and the actual process used in specific situations. Th= is >> would analogous to asking for a spec around the actual way in which BGP >> tables are stored (rather than the theoretical model proposed in the BGP >> specs). >=20 > I disagree with your analogy. > IMO, the BGP analogy is, within an AS, following an internal route change,= to trigger BGP route re-computation at the same time across vendors. e.g. a= gree on the mechanism (e.g. BGP scan time vs triggered computation). > (but it's still a bit different as for BGP you could use tunnels between A= SBR to avoid hitting RIB inconsistencies) >=20 >> I see a couple of problems with going down this path -- the most >> prominent of which is that it kills off the ability to think of better wa= ys to >> implement the functionality under discussion. >=20 > I disagree. cf slide 7 http://tools.ietf.org/agenda/90/slides/slides-90-rt= gwg-2.pdf >=20 >=20 >=20 >> Given all of this, the problem we have is that different implementations b= ack >> off in different ways, which causes microloops and microblackholes. >=20 > +1 >=20 >> If we set >> upper and lower bounds on the time to react in each given situation, then= >> we're solving that problem without telling people how to get to those upp= er >> and lower bounds. If we propose an actual algorithm, then we're telling >> people not only what must happen, but how it must happen. I suspect we're= >> crossing a line in there someplace that reaches outside the IETF's scope.= >=20 > We need "close"/identical values, across all nodes, for _all_ the steps of= the back-off algorithm/spec. =46rom the first event of the set of consecuti= ve events, up to the last events. > If we have a 2 steps back-off algorithm (fast - slow) I guess setting the u= pper and lower bound is enough. But this assumes that we all agree on this 2= steps mechanism/algo. (while we/vendors don't today) > We also need to define how we determine this set of consecutive events. An= d make sure we are consistent about which are those events (e.g. refresh LSA= /LSP are not). >=20 >> Hence, I would argue for a BCP that says, "this is what must happen and >> when," which would be similar to telling BGP implementors the way >> dampening should look from another implementation's point of view... The >> implementation is still (pretty much) a block box. I don't know if we sho= uld >> slip over the line into telling people how to implement. >>=20 >> I'm willing to be persuaded, I just don't see the argument for specifying= an >> algorithm with what's been put on the table to this point. >=20 > Ok. So I guess my presentation/draft was not clear enough.=20 > Can we try to sync face to face during this week? >=20 > Thanks, > Bruno >>=20 >> :-) >>=20 >> Russ >=20 >=20 > __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confide= ntielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged in= formation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and del= ete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been= modified, changed or falsified. > Thank you. >=20 From nobody Thu Jul 24 14:05:52 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B661A0AD3 for ; Thu, 24 Jul 2014 14:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_2SSpTBAVft for ; Thu, 24 Jul 2014 14:05:47 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C431A0AA3 for ; Thu, 24 Jul 2014 14:05:46 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-df-53d11fb399ae Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C6.75.25146.3BF11D35; Thu, 24 Jul 2014 17:01:08 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 17:05:44 -0400 From: Antoni Przygienda To: "rtgwg@ietf.org" Subject: MINIMIZE BACKOFF SPF two technical points Thread-Topic: MINIMIZE BACKOFF SPF two technical points Thread-Index: Ac+ngwLI0e/eJJ8oQFm6eqa2+cTV1w== Date: Thu, 24 Jul 2014 21:05:43 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F18161B96@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F18161B96eusaamb103ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyuXRPiO4W+YvBBgeuclpcePOb2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGef7jrAUvM2t2HfvH1MD4+z4LkZODgkBE4lTN+4wQdhiEhfu rWfrYuTiEBI4yiix8OFFVghnOaPEyre/mUGq2AQsJC5/ewpmiwioSvTOamUDsYUFjCTmN79m 6WLkAIqbS/S9qYQo0ZPY0LKPGSTMAlR+9L4cSJhXwFti/bsbLCA2I9De76fWgN3ALCAucevJ fKh7BCSW7DnPDGGLSrx8/I8VwlaSmPP6GjNEfb7EkwUPGCFmCkqcnPmEZQKj0Cwko2YhKZuF pAwiriexc9d/dghbW2LZwtfMs4AuZRbQlZjZV4QsvICRfRUjR2lxalluupHhJkZg0B+TYHPc wbjgk+UhRgEORiUe3gXt54OFWBPLiitzDzFKc7AoifNqVs8LFhJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cAo67V6Qa9lVGL/kl1nBcXm9fD/FnrZp/P9QnXrB33RvSxvH3PfzmW4vnxxeO+H BTPVxRZE+y51F1ZeK9zUIO+4geVdltvZ+ZPSz3/19bfNkkvkaVj421ch6Bz/wvRNiVcYjZMO u/9ed8Jy9/95CmkcloIOnlXHbwdK33F2mLIjYNfpiQqeEcVKLMUZiYZazEXFiQBIJq+SWwIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/ZSCxxCB7OK2J6cogoYdRvr_IeCc X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 21:05:50 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F18161B96eusaamb103ericsso_ Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable As first, I'm supportive for the work & I think it's of solid applicable va= lue albeit it's strictly not IETF territory (it's not necessary for interop= strictly speaking). First is very blunt: if you manage to really make all the routers in the a= rea compute @ precisely the same time, you may not be doing yourself the fa= vor you seek ;-) What I mean is that generating perfectly synchronized pea= ks in a network tends to generate strange attractors, a good example was th= e synchronization of the HELLOs on all links over time that had to be jitte= red. Peaks can stress infra unexpectedly & lead to e.g. synchronized re-adv= ertisement of LSAs (or anything that SPF can trigger now and in the future= ). Given on top that an SPF in the future is not necessarily the 2-3 msec = SPF seen today (rLFA & such runs seem to become the new flavor of SPF) I su= ggest to include a small configurable jitter before the first SPF is trigge= red (couple msecs should do the trick but I'm willing to hear the argument = that flooding de-sync's the SPF runs enough already). The other issue is far more subtle but may merit a section in the draft. T= his work is pushing the protocol in a very specific direction along the CAP= paradigm, i.e. a link-state routing protocol is roughly 1. Always 100% P (partitioned) 2. Basically 100% available A (tad hard to define given FIBs) 3. _eventually_ consistent C Now, it is fairly well understood that having all 3 is not possible across = very wide set of CS problems and we are not exempt of that. We cannot move= P so pushing on the C will cause A to move to the negative. Now, what do = I mean by that. Triggering the SPFs more aggressively will give you better= consistent&available in the scenario of a single link failure if things go= well. Now, compared to e.g. a batching algorithm that computes every 500 m= secs without backing off and will show linear consistent&available even in = case of fast-link flapping, many links failing consecutively and so on, exp= onential backoff will cause massively lower consistency after several link = failure and this network-wide so certain people may loose big time when usi= ng that. Beside that, the quick SPFs can block lots of other things in the = protocol that are not parallelized or block other protocols waiting for SPF= s to finish or next SPF (2nd failure) stuck on FIB download running (all hy= pothetical, but availability in widest sense will go down if you see more c= onsistency). Again, the work is good but the section will show people that = it's not an 'universal' improvement but something triggered to ideally a se= ldom occurring 1 or 2 links failure. Thanks --- tony "FUTURE, n. That period of time in which our affairs prosper, our friends are true and = our happiness is assured." =AF Ambrose Bierce, The Unabridged Devil's Dictionary --_000_2E4BB27CAB87BF43B4207C0E55860F18161B96eusaamb103ericsso_ Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable

As first, I’m supportive for the work & I think it= ’s of solid applicable value albeit it’s strictly not IETF terr= itory (it’s not necessary for interop strictly speaking).

First is very blunt: if you manage to really make all = the routers in the area compute @ precisely the same time, you may not be d= oing yourself the favor you seek ;-) What I mean is that generating perfectly synchronized peaks in a network tends to= generate strange attractors, a good example was the synchronization of the= HELLOs on all links over time that had to be jittered. Peaks can stress in= fra unexpectedly & lead to e.g. synchronized re-advertisement of LSAs (or anything that SPF can trig= ger now and in the future). Given on top that an SPF in the future is= not necessarily the 2-3 msec SPF seen today (rLFA & such runs seem to = become the new flavor of SPF) I suggest to include a small configurable jitter before the first SPF is triggered (couple msec= s should do the trick but I’m willing to hear the argument that flood= ing de-sync’s the SPF runs enough already).

The other issue is far more subtle but may merit a section i= n the draft. This work is pushing the protocol in a very specific dir= ection along the CAP paradigm, i.e. a link-state routing protocol is roughly

1. Always 100% P (partitioned)

2. Basically 100% available = ;A (tad hard to define given FIBs)

3. _eventually_ consistent C

Now, it is fairly well understood that having all 3 is not p= ossible across very wide set of CS problems and we are not exempt of that.&= nbsp; We cannot move P so pushing on the C will cause A to move to the negative. Now, what do I mean by that. Trigge= ring the SPFs more aggressively will give you better consistent&availab= le in the scenario of a single link failure if things go well. Now, compare= d to e.g. a batching algorithm that computes every 500 msecs without backing off and will show linear consistent&av= ailable even in case of fast-link flapping, many links failing consecutivel= y and so on, exponential backoff will cause massively lower consistency aft= er several link failure and this network-wide so certain people may loose big time when using that. Beside that, the qui= ck SPFs can block lots of other things in the protocol that are not paralle= lized or block other protocols waiting for SPFs to finish or next SPF (2nd failure) stuck on FIB download running (all hypothetical, but availability in widest sense will = go down if you see more consistency). Again, the work is good but the secti= on will show people that it’s not an ‘universal’ improvem= ent but something triggered to ideally a seldom occurring 1 or 2 links failure.

Thanks

--- tony

“FUTURE, n.
That period of time in which our affairs prosper, our friends are true and = our happiness is assured.”
=AF= Ambrose Bierce= , The Unabr= idged Devil's Dictionary

--_000_2E4BB27CAB87BF43B4207C0E55860F18161B96eusaamb103ericsso_-- From nobody Thu Jul 24 15:01:37 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AF51A026E for ; Thu, 24 Jul 2014 15:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8d4Ab7vs2rJ for ; Thu, 24 Jul 2014 15:01:35 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A831A0194 for ; Thu, 24 Jul 2014 15:01:34 -0700 (PDT) Received: from dhcp-9565.meeting.ietf.org ([31.133.149.101]:54945 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1XAR4v-0005rf-Ql; Thu, 24 Jul 2014 22:01:33 +0000 From: "Russ White" To: "'Antoni Przygienda'" , References: <2E4BB27CAB87BF43B4207C0E55860F18161B96@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F18161B96@eusaamb103.ericsson.se> Subject: RE: MINIMIZE BACKOFF SPF two technical points Date: Thu, 24 Jul 2014 18:01:29 -0400 Message-ID: <075201cfa78a$d35da990$7a18fcb0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG2vSRQp4TfXR1XXvd32MdBJU95bpvhmjeg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/AlzbDJkLgXD4C43BPnvn8S31gNQ X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 22:01:36 -0000 > The other issue is far more subtle but may merit a section in the draft. This > work is pushing the protocol in a very specific direction along the CAP > paradigm, i.e. a link-state routing protocol is roughly This is a great reminder of the cap theorem -- thanks for bringing this into the flow of thought. Strictly speaking, making all the routers do the same thing in terms of timing isn't asking for better consistency, but rather consistency of consistency (meta consistency, anyone?). But it still largely applies here -- if you try to control the consistency of a distributed database in a strong way, you're going to give up availability or partitionability -- I suspect both. > wide set of CS problems and we are not exempt of that. We cannot move P > so pushing on the C will cause A to move to the negative. Correct -- which is why I think a set of parameters and a suggested set of settings is the most important point here, rather than trying to "solve the problem." :-) Russ From nobody Fri Jul 25 09:43:22 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3530F1A03AD for ; Fri, 25 Jul 2014 09:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycrblToh5MHc for ; Fri, 25 Jul 2014 09:43:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4546E1A0387 for ; Fri, 25 Jul 2014 09:43:19 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 79C93325B2C; Fri, 25 Jul 2014 18:43:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 577E94C071; Fri, 25 Jul 2014 18:43:17 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.91]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Fri, 25 Jul 2014 18:43:16 +0200 From: To: Hannes Gredler , DECRAENE Bruno IMT/OLN , Russ White Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQHPpzvUfDZOmpkuSUWGoaZndaas2puvcjKw///qPgCAAAPOgIAAApeAgAANIACAAAIJgIAAAeCAgAGJqNA= Date: Fri, 25 Jul 2014 16:43:15 +0000 Message-ID: <28467_1406306597_53D28925_28467_14138_1_5be0356e-4729-48ba-af44-b51fb5cd883e@OPEXCLILH05.corporate.adroot.infra.ftgroup> References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <061001cfa769$6c85b3a0$45911ae0$@riw.us> <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup>, <23003_1406228198_53D156E6_23003_17158_1_53C29892C857584299CBF5D05346208A0718FDB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1406228599846.53663@juniper.net> In-Reply-To: <1406228599846.53663@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.25.113919 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/9ic6m9mcUkzhXOk0sHCDAC3eV3A Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:43:21 -0000 Hannes, I agree with you at now routers are able to handle multiple events in a sho= rt time but anyway : - delaying is always necessary (I can't really see how we can go under 100/= 150ms) : If you go to something like 0 or 5 msec, we may fall into implementations = issues with constant READ/WRITE contentions in FIB that often cause corner = cases where the router is completely lost in what it must do Moreover in case of complex outage (node failure or SRLG failure) where mu= ltiple LSPs are sent. We must ensure that all LSPs are received before comp= uting SPF to ensure that the target topology is a good one. - Increasing delay is also necessary. By experience there are situations wh= ere you need absolutely to calm down computation to prevent churn amplifica= tion (even today with stronger CPUs) - we need to ensure that increasing delay steps are not so big, so in case = of router unsynchronization (in delay value), the difference would be small. - as agreed , we can run more fast scheduled SPFs Both current implementations (two steps and backoff) do no fill these "requ= irements". I would be in favor of standardizing something really simple with no mathem= atic underway. Just extend the two steps to an N-Step tunable system that t= he operator can manage. Something like defining a WRED profile but without interpolation. Example : Initial : 100 ms, 4 runs 2nd : 200ms, 2 runs 3rd : 300ms, 2 runs 4th : 500ms, 2 runs 5th : 700ms, 2 runs 6th : 800ms, 2 runs 7th : 1s, all subsequent runs -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Hannes Gredler Sent: Thursday, July 24, 2014 15:03 To: DECRAENE Bruno IMT/OLN; Russ White Cc: rtgwg@ietf.org Subject: RE: On minimizing SPF backoff induced blackouts hi bruno, IMO the problem that you're trying to solve is to have the routers still be= ing responsive when multiple events are happening in the network. wouldn't then a simple fix be to kick the SPF pacing logic at a much more l= ater point in time ? - i.e. rather than slowing down things down on event #= 2 or #3, do it at event # (please insert you're favorite number for ) /hannes ________________________________________ From: rtgwg on behalf of bruno.decraene@orange.com= Sent: Thursday, July 24, 2014 20:56 To: Russ White Cc: rtgwg@ietf.org Subject: RE: On minimizing SPF backoff induced blackouts > > I'm willing to be persuaded, I just don't see the argument for=20 > > specifying an algorithm with what's been put on the table to this point. > > Ok. So I guess my presentation/draft was not clear enough. Let me try again. In slide 5: http://tools.ietf.org/agenda/90/slides/slides-90-rtgwg-2.pdf - do we agree that it would be better if node A and B both schedule their S= PF at roughly the same time? i.e. wait for the same duration? - if so, what would be your proposition? Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jul 25 10:58:00 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA1C1A02A0 for ; Fri, 25 Jul 2014 10:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8emMoPBq-Pq for ; Fri, 25 Jul 2014 10:57:57 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFF81A0025 for ; Fri, 25 Jul 2014 10:57:57 -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 s6PHvoKF017454; Fri, 25 Jul 2014 18:57:50 +0100 Received: from 950129200 (dhcp-b3a5.meeting.ietf.org [31.133.179.165]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s6PHvmOq017433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jul 2014 18:57:50 +0100 From: "Adrian Farrel" To: Subject: Call for review draft-farrkingel-pce-abno-architecture Date: Fri, 25 Jul 2014 18:57:52 +0100 Message-ID: <063201cfa831$f590dfd0$e0b29f70$@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: Ac+oMc1A+LGTfdqlRv2VsG97zNF99A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20840.001 X-TM-AS-Result: No--3.520-10.0-31-10 X-imss-scan-details: No--3.520-10.0-31-10 X-TMASE-MatchedRID: OOE19uLU/P8e5COU7dNCwuyNEc7z2JzC3E5VFJRbiIRrE1c4mB5UmhZ6 8yUnXFgf+8l6jFSki7pANiMqn4yGugt3e7z0WipRngIgpj8eDcC063Wh9WVqgpgZQ9043V5e+gt Hj7OwNO2OhzOa6g8KrXhQXKpqUH/WSzjzhLTEnEDaHdo7qSRQwexQUV65t62TJWd9PODOshrkP2 yapUEP3KKWedUMQI938fsC+xPFkxvsNp90fT4EjuoLJh5uXtfs Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/dMOhEpmXJ3zHMUdHML8QBm7HJiU Cc: draft-farrkingel-pce-abno-architecture@tools.ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:57:59 -0000 Hi, The authors of draft-farrkingel-pce-abno-architecture are in the process of requesting AD-sponsored publication of draft-farrkingel-pce-abno-architecture This I-D is a bit of an architecture and a bit an applicability statement. It spans quite a lot of IETF technology. The last call will obviously pop out sometime, but it would be nice to have review comments before then. Thanks, Adrian From prvs=2285b65ae3=petr@fb.com Sun Jul 27 10:31:07 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AAE1A0AB9 for ; Sun, 27 Jul 2014 10:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txRsZ65hZK20 for ; Sun, 27 Jul 2014 10:31:06 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4D21A0ACA for ; Sun, 27 Jul 2014 10:31:01 -0700 (PDT) Received: from pps.filterd (m0004060 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id s6RHUhxd025198 for ; Sun, 27 Jul 2014 10:31:01 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=facebook; bh=cME2Rl8iF3AwLtZpa5B/nnS6KozAdo+z5Hk/6GUgZC4=; b=MIBlKIYPjmDq8ly2Gy5bFs2gik0WdvBWf+d/MYEENfc0hD+VYQj7y4kXZ/BxTkPJRmo1 RARMWLm4KShPLr6uJeKssbKCgP0ajQZIXDVZYZzURaAXebv/hMvFJGvSss45oGWG8ihY BSNjUnApyqber4CnNhMl2ggSF10N/NRmuSE= Received: from mail.thefacebook.com (mailwest.thefacebook.com [173.252.71.148]) by mx0b-00082601.pphosted.com with ESMTP id 1nc95db7jm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Sun, 27 Jul 2014 10:31:01 -0700 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.4.16]) by PRN-CHUB04.TheFacebook.com ([fe80::7ded:c10e:ef04:80d8%12]) with mapi id 14.03.0195.001; Sun, 27 Jul 2014 10:30:59 -0700 From: Petr Lapukhov To: "rtgwg@ietf.org" Subject: WG review for draft-lapukhov-bgp-routing-large-dc Thread-Topic: WG review for draft-lapukhov-bgp-routing-large-dc Thread-Index: Ac+pvX4ulhpAwYRMTEGWPzvHfPFNvg== Date: Sun, 27 Jul 2014 17:30:58 +0000 Message-ID: <3F437107848A5140A6A19222EFFB34811FC80399@PRN-MBX01-2.TheFacebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-27_02:2014-07-25,2014-07-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=4.21265701211482e-08 kscore.compositescore=0 circleOfTrustscore=72.52 compositescore=0.999779992635723 urlsuspect_oldscore=0.999779992635723 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=9065 rbsscore=0.999779992635723 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407270228 X-FB-Internal: deliver Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/uWIepBoeSOSxwRR5DAj993bhMYA X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 17:44:58 -0000 Hi, Authors of draft-lapukhov-bgp-routing-large-dc would like to submit it for = WG review and possible adoption as a workgroup document. In this draft we s= ummarize our experience of using BGP as the only protocol for routing in la= rge-scale data-center networks (100K+ bare metal servers, multiple thousand= s of routers).=20 Document location: http://tools.ietf.org/html/draft-lapukhov-bgp-routing-la= rge-dc/ Thank you! Petr= From nobody Mon Jul 28 02:36:17 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE45E1A0359 for ; Mon, 28 Jul 2014 02:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltAILjfbsD2o for ; Mon, 28 Jul 2014 02:36:10 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998341A034A for ; Mon, 28 Jul 2014 02:36:09 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: "stephane.litkowski@orange.com" , "Hannes Gredler" , DECRAENE Bruno IMT/OLN , Russ White Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQHPpzvVjLUa5FqabU2C7d/ikbFCbpuvUSiAgAALSACAAAPOgIAAApeAgAANIACAAAIJgIAAAeCAgAFrMoCABFvYAA== Date: Mon, 28 Jul 2014 09:36:07 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B02387616@EX01.swan.local> References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <061001cfa769$6c85b3a0$45911ae0$@riw.us> <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup>, <23003_1406228198_53D156E6_23003_17158_1_53C29892C857584299CBF5D05346208A0718FDB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1406228599846.53663@juniper.net> <28467_1406306597_53D28925_28467_14138_1_5be0356e-4729-48ba-af44-b51fb5cd883e@OPEXCLILH05.corporate.adroot.infra.ftgroup> In-Reply-To: <28467_1406306597_53D28925_28467_14138_1_5be0356e-4729-48ba-af44-b51fb5cd883e@OPEXCLILH05.corporate.adroot.infra.ftgroup> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.44.10] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/hUBRuRYrGEIarGbY0AgSmDP95zc Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 09:36:15 -0000 Stephane, My opinion is that majority of the changes in backbones can be described by= a single or two LSPs.=20 So modern routers the initial wait is unnecessary in most of the cases or i= s roughly equal to network jitter.=20 If there's a major failure you might want to wait for roughly the full or 1= /2 of the time it takes the LSPs to be propagated from one end of your netw= ork to the other end + the delay variation (this of course would be differe= nt for each network). That is when you would like the SPF to converge asap. However with FRR at hand we can go with whatever the common default timers = are gonna be.=20 adam > -----Original Message----- > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of > stephane.litkowski@orange.com > Sent: Friday, July 25, 2014 6:43 PM > To: Hannes Gredler; DECRAENE Bruno IMT/OLN; Russ White > Cc: rtgwg@ietf.org > Subject: RE: On minimizing SPF backoff induced blackouts >=20 > Hannes, >=20 > I agree with you at now routers are able to handle multiple events in a s= hort > time but anyway : > - delaying is always necessary (I can't really see how we can go under > 100/150ms) : > If you go to something like 0 or 5 msec, we may fall into > implementations issues with constant READ/WRITE contentions in FIB that > often cause corner cases where the router is completely lost in what it m= ust > do > Moreover in case of complex outage (node failure or SRLG failure) > where multiple LSPs are sent. We must ensure that all LSPs are received > before computing SPF to ensure that the target topology is a good one. >=20 > - Increasing delay is also necessary. By experience there are situations = where > you need absolutely to calm down computation to prevent churn > amplification (even today with stronger CPUs) > - we need to ensure that increasing delay steps are not so big, so in cas= e of > router unsynchronization (in delay value), the difference would be small. > - as agreed , we can run more fast scheduled SPFs >=20 > Both current implementations (two steps and backoff) do no fill these > "requirements". >=20 > I would be in favor of standardizing something really simple with no > mathematic underway. Just extend the two steps to an N-Step tunable > system that the operator can manage. > Something like defining a WRED profile but without interpolation. > Example : >=20 > Initial : 100 ms, 4 runs > 2nd : 200ms, 2 runs > 3rd : 300ms, 2 runs > 4th : 500ms, 2 runs > 5th : 700ms, 2 runs > 6th : 800ms, 2 runs > 7th : 1s, all subsequent runs >=20 >=20 >=20 > -----Original Message----- > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Hannes Gredler > Sent: Thursday, July 24, 2014 15:03 > To: DECRAENE Bruno IMT/OLN; Russ White > Cc: rtgwg@ietf.org > Subject: RE: On minimizing SPF backoff induced blackouts >=20 > hi bruno, >=20 > IMO the problem that you're trying to solve is to have the routers still = being > responsive when multiple events are happening in the network. >=20 > wouldn't then a simple fix be to kick the SPF pacing logic at a much more= later > point in time ? - i.e. rather than slowing down things down on event #2 o= r #3, > do it at event # (please insert you're favorite number for ) >=20 > /hannes >=20 > ________________________________________ > From: rtgwg on behalf of > bruno.decraene@orange.com > Sent: Thursday, July 24, 2014 20:56 > To: Russ White > Cc: rtgwg@ietf.org > Subject: RE: On minimizing SPF backoff induced blackouts >=20 > > > I'm willing to be persuaded, I just don't see the argument for > > > specifying an algorithm with what's been put on the table to this poi= nt. > > > > Ok. So I guess my presentation/draft was not clear enough. >=20 > Let me try again. > In slide 5: http://tools.ietf.org/agenda/90/slides/slides-90-rtgwg-2.pdf > - do we agree that it would be better if node A and B both schedule their= SPF > at roughly the same time? i.e. wait for the same duration? > - if so, what would be your proposition? >=20 > Bruno >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Mon Jul 28 03:42:00 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF051A03C9 for ; Mon, 28 Jul 2014 03:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfXdVJxqgXrL for ; Mon, 28 Jul 2014 03:41:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF3F1A03BF for ; Mon, 28 Jul 2014 03:41:56 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 568C6C14EC; Mon, 28 Jul 2014 12:41:54 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 2F35BC805D; Mon, 28 Jul 2014 12:41:54 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 28 Jul 2014 12:41:54 +0200 From: To: Antoni Przygienda Subject: RE: MINIMIZE BACKOFF SPF two technical points Thread-Topic: MINIMIZE BACKOFF SPF two technical points Thread-Index: Ac+ngwLI0e/eJJ8oQFm6eqa2+cTV1wCySv9w Date: Mon, 28 Jul 2014 10:41:52 +0000 Message-ID: <10861_1406544114_53D628F2_10861_375_4_53C29892C857584299CBF5D05346208A071923D5@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <2E4BB27CAB87BF43B4207C0E55860F18161B96@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F18161B96@eusaamb103.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.123022 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/TUJQxVGMnJbZ5CbRSmgPJyE0-0I Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 10:41:58 -0000 Hi Antoni, Thanks for your feedback. More inlined. > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Antoni Przygien= da > Sent: Thursday, July 24, 2014 11:06 PM >=20 > As first, I'm supportive for the work & I think it's of solid applicable = value Thank you. > albeit it's strictly not IETF territory (it's not necessary for interop s= trictly > speaking). >=20 > First is very blunt:=A0 if you manage to really make all the routers in t= he area > compute @ precisely the same time, you may not be doing yourself the favor > you seek ;-)=A0 What I mean is that generating perfectly synchronized pea= ks in a > network tends to generate strange attractors, a good example was the > synchronization of the HELLOs on all links over time that had to be jitte= red. > Peaks can stress infra unexpectedly & lead to e.g. synchronized re- > advertisement of LSAs=A0 (or anything that SPF can trigger now and in the > future). =A0Given on top that an SPF in the future is not necessarily the= 2-3 > msec SPF seen today (rLFA & such runs seem to become the new flavor of > SPF) I suggest to include a small configurable jitter before the first SP= F is > triggered (couple msecs should do the trick but I'm willing to hear the > argument that flooding de-sync's the SPF runs enough already). Interesting feedback. We'll try to keep it in mind. FYI, note that so far we mainly had the opposite feedback: "You'll never ma= nage to have a perfect synchronization. e.g. CPU scheduler delay between ro= uters) =20 > The other issue is far more subtle but may merit a section in the draft.= =A0 This > work is pushing the protocol in a very specific direction along the CAP > paradigm, i.e. a link-state routing protocol is roughly >=20 > 1. Always 100% P (partitioned) > 2. Basically 100% available =A0A =A0(tad hard to define given FIBs) 3. _e= ventually_ > consistent C >=20 > Now, it is fairly well understood that having all 3 is not possible acros= s very > wide set of CS problems and we are not exempt of that.=A0 We cannot move > P=A0 so pushing on the C will cause A to move to the negative. Now, what = do I > mean by that.=A0=20 Well, I'm not an expert in theoretical computer science but: - there seem be a debate on CAP itself - I'm not sure it's applicable to SPF delay. In particular, SPF delay has n= o influence on the LSDB and hence in particular about its Consistency, Avai= lability, and tolerance to Partition. Also, the proof of the CAP theorem se= ems to be limited to a replicated distributed system, while in LS IGP, only= a single node is allowed to modify a given data (LSP/LSA) so we don't have= the issue of a distributed system which gets partitioned and where we have= 2 simultaneous conflicting requests (asking for a different change). >Triggering the SPFs more aggressively will give you better > consistent&available in the scenario of a single link failure if things g= o well. > Now, compared to e.g. a batching algorithm that computes every 500 msecs > without backing off and will show linear consistent&available even in cas= e of > fast-link flapping, many links failing consecutively and so on, exponenti= al > backoff will cause massively lower consistency after several link failure= and > this network-wide so certain people may loose big time when using that. > Beside that, the quick SPFs can block lots of other things in the protoco= l that > are not parallelized or block other protocols waiting for SPFs to finish = or next > SPF (2nd failure) stuck on FIB download running (all hypothetical, but > availability in widest sense will go down if you see more consistency). A= gain, > the work is good but the section will show people that it's not an 'unive= rsal' > improvement but something triggered to ideally a seldom occurring 1 or 2 > links failure. Let's step back a little bit on these 2 comments and in particular the CAP = one. The draft proposes to specify a common SPF delay specification. (full point= ). At most (best IMHO, worst related to your CAP comment): - only the SPF delay is changed - all nodes uses the same spec. I don't think it's possible to claim that there is a theoretical issue/risk= , because a mono vendor AS (using the same implementation on all nodes) is = going much further in term of consistent behavior. And I don't think that a= ny vendor will say that in such circumstance, its implementation does not w= ork or is more risky, and the AS MUST /SHOULD introduce another vendor. Link State IGP do work even in mono-vendor network with all nodes running t= he same code and hence the same spec. Thanks, Bruno > Thanks >=20 > --- tony >=20 >=20 >=20 > "FUTURE, n. > That period of time in which our affairs prosper, our friends are true an= d our > happiness is assured." > =AF Ambrose Bierce, The Unabridged Devil's Dictionary >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Jul 28 06:49:01 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266061B280C for ; Mon, 28 Jul 2014 06:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p24iUU7YbxJM for ; Mon, 28 Jul 2014 06:48:59 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BF61B27FC for ; Mon, 28 Jul 2014 06:48:58 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id bc456d35.2b3bb8a00940.3523695.00-2455.9084678.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 28 Jul 2014 13:48:59 +0000 (UTC) X-MXL-Hash: 53d654cb4fb582e2-882ec48768a0590397fa60337b58eeae6421623e Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 5c456d35.0.3523654.00-2371.9084544.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 28 Jul 2014 13:48:55 +0000 (UTC) X-MXL-Hash: 53d654c71eea4167-559daab3f1b8dfb4818c68d1bd146a5b51ce0e46 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6SDmr21029969; Mon, 28 Jul 2014 09:48:53 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6SDmh64029791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 09:48:46 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 28 Jul 2014 13:48:28 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.67]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0174.001; Mon, 28 Jul 2014 09:48:28 -0400 From: "UTTARO, JAMES" To: "'Petr Lapukhov'" , "'rtgwg@ietf.org'" Subject: RE: WG review for draft-lapukhov-bgp-routing-large-dc Thread-Topic: WG review for draft-lapukhov-bgp-routing-large-dc Thread-Index: Ac+pvX4ulhpAwYRMTEGWPzvHfPFNvgArU9aQ Date: Mon, 28 Jul 2014 13:48:28 +0000 Message-ID: References: <3F437107848A5140A6A19222EFFB34811FC80399@PRN-MBX01-2.TheFacebook.com> In-Reply-To: <3F437107848A5140A6A19222EFFB34811FC80399@PRN-MBX01-2.TheFacebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.240] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Y+xPRGiN c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=gq458an3M68A:10 a=ofMgfj31e3cA:10 a=tKHq4Ej1SzYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=xaBp2gifDU3RMsENTl4A:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/1oRN7cmlXt2AOhBBK5RwkNMGDHY X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:49:00 -0000 Support Jim Uttaro -----Original Message----- From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Petr Lapukhov Sent: Sunday, July 27, 2014 1:31 PM To: rtgwg@ietf.org Subject: WG review for draft-lapukhov-bgp-routing-large-dc Hi, Authors of draft-lapukhov-bgp-routing-large-dc would like to submit it for = WG review and possible adoption as a workgroup document. In this draft we s= ummarize our experience of using BGP as the only protocol for routing in la= rge-scale data-center networks (100K+ bare metal servers, multiple thousand= s of routers).=20 Document location: http://tools.ietf.org/html/draft-lapukhov-bgp-routing-la= rge-dc/ Thank you! Petr _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From nobody Mon Jul 28 07:39:08 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29271A0292; Mon, 28 Jul 2014 07:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcFvq040Nv0H; Mon, 28 Jul 2014 07:39:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA5D1A0385; Mon, 28 Jul 2014 07:39:04 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 0D87A3B4360; Mon, 28 Jul 2014 16:39:03 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id E88C51800AC; Mon, 28 Jul 2014 16:39:02 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 28 Jul 2014 16:39:02 +0200 From: To: Petr Lapukhov , "rtgwg@ietf.org" Subject: RE: WG review for draft-lapukhov-bgp-routing-large-dc Thread-Topic: WG review for draft-lapukhov-bgp-routing-large-dc Thread-Index: Ac+pvX4ulhpAwYRMTEGWPzvHfPFNvgAs5s9w Date: Mon, 28 Jul 2014 14:39:01 +0000 Message-ID: <20194_1406558343_53D66086_20194_232_1_53C29892C857584299CBF5D05346208A07192B00@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <3F437107848A5140A6A19222EFFB34811FC80399@PRN-MBX01-2.TheFacebook.com> In-Reply-To: <3F437107848A5140A6A19222EFFB34811FC80399@PRN-MBX01-2.TheFacebook.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.123022 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/UxNWoMTb6Ku_sJNIiJHfhS-zeME Cc: "grow-chairs@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:39:06 -0000 Support. Wouldn't GROW be a better home than RTGWG? > -----Original Message----- > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Petr Lapukhov > Sent: Sunday, July 27, 2014 7:31 PM > To: rtgwg@ietf.org > Subject: WG review for draft-lapukhov-bgp-routing-large-dc >=20 > Hi, >=20 > Authors of draft-lapukhov-bgp-routing-large-dc would like to submit it for > WG review and possible adoption as a workgroup document. In this draft we > summarize our experience of using BGP as the only protocol for routing in > large-scale data-center networks (100K+ bare metal servers, multiple > thousands of routers). >=20 > Document location: http://tools.ietf.org/html/draft-lapukhov-bgp-routing- > large-dc/ >=20 > Thank you! >=20 > Petr > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Jul 28 08:07:49 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11491B2891 for ; Mon, 28 Jul 2014 08:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_jRJCdj5zEK for ; Mon, 28 Jul 2014 08:07:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4781B2888 for ; Mon, 28 Jul 2014 08:07:39 -0700 (PDT) Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by CO1PR05MB267.namprd05.prod.outlook.com (10.141.71.12) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 15:07:38 +0000 Received: from juniper.net (193.110.55.12) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 15:07:35 +0000 Date: Mon, 28 Jul 2014 17:07:18 +0200 From: Hannes Gredler To: Subject: Re: On minimizing SPF backoff induced blackouts Message-ID: <20140728150718.GA17910@juniper.net> References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <061001cfa769$6c85b3a0$45911ae0$@riw.us> <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup> <23003_1406228198_53D156E6_23003_17158_1_53C29892C857584299CBF5D05346208A0718FDB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1406228599846.53663@juniper.net> <28467_1406306597_53D28925_28467_14138_1_5be0356e-4729-48ba-af44-b51fb5cd883e@OPEXCLILH05.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <28467_1406306597_53D28925_28467_14138_1_5be0356e-4729-48ba-af44-b51fb5cd883e@OPEXCLILH05.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: AM3PR06CA061.eurprd06.prod.outlook.com (10.141.192.179) To CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0286D7B531 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(24454002)(243025005)(13464003)(51704005)(57704003)(189002)(199002)(83506001)(102836001)(15975445006)(69596002)(87976001)(105586002)(21056001)(85852003)(101416001)(93886003)(92726001)(99396002)(92566001)(107046002)(95666004)(79102001)(76176999)(33656002)(85306003)(50986999)(110136001)(81156004)(106356001)(77096002)(64706001)(54356999)(2351001)(66066001)(80022001)(97756001)(36756003)(46102001)(77982001)(76482001)(23726002)(4396001)(15202345003)(47776003)(42186005)(86362001)(74502001)(83072002)(74662001)(81542001)(81342001)(83322001)(19580395003)(19580405001)(31966008)(20776003)(50466002)(46406003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:juniper.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/2KznO0n6RYXrl0a7-9zkotwWDkg Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:07:48 -0000 On Fri, Jul 25, 2014 at 04:43:15PM +0000, stephane.litkowski@orange.com wrote: | I agree with you at now routers are able to handle multiple events in a short time but anyway : | - delaying is always necessary (I can't really see how we can go under 100/150ms) : the only reason it is necessary is that some implementations (ours included) do some state compression, such that there is a collection window of 20ms of local-events. strictly speaking thats just a efficiency/responsiveness tradeoff and we got some requests in the past to lower that window. | If you go to something like 0 or 5 msec, we may fall into implementations issues with constant READ/WRITE contentions in FIB that often cause corner cases where the router is completely lost in what it must do again thats implementation dependent. if you have now state-compression on your RIB/FIB path then you're doomed anyway. state of the art is that you do not de-queue route 'N(t)' if route 'N(t+1)' is available, but cancel N(t) update. | Moreover in case of complex outage (node failure or SRLG failure) where multiple LSPs are sent. We must ensure that all LSPs are received before computing SPF to ensure that the target topology is a good one. see and this i do not believe is possible. whatever SPF initial wait will be, there will be always incidents where the LSP triggers arrives after , so there will be always corner cases for loops. | - Increasing delay is also necessary. By experience there are situations where you need absolutely to calm down computation to prevent churn amplification (even today with stronger CPUs) no doubt - the question is when do we need to kick in that self-protection layer ... is it after reception of the 2nd LSP or after the 10th ? | - we need to ensure that increasing delay steps are not so big, so in case of router unsynchronization (in delay value), the difference would be small. | - as agreed , we can run more fast scheduled SPFs | | Both current implementations (two steps and backoff) do no fill these "requirements". rapid-run in a certain way does because it is widening your window of 'concurrent, unrelated network events' without going into backup mode. | I would be in favor of standardizing something really simple with no mathematic underway. Just extend the two steps to an N-Step tunable system that the operator can manage. | Something like defining a WRED profile but without interpolation. | Example : | | Initial : 100 ms, 4 runs | 2nd : 200ms, 2 runs | 3rd : 300ms, 2 runs | 4th : 500ms, 2 runs | 5th : 700ms, 2 runs | 6th : 800ms, 2 runs | 7th : 1s, all subsequent runs as tony (and others) have pointed out ... it will only work during nice-weather conditions ... as soon as you have the perfect-storm, you will have micro loops (and all the pain you try to protect yourself) - therefore i'd be much more in favour of 'something else' which gets us to zero uloops, and for that i am afraid we need to have the notions of independent forwarding planes (ala make before break) - trying to synchronize RIB/FIB update across different CPUs/routing-stacks/vendors/load conditions is a battle that can never be won. /hannes | -----Original Message----- | From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Hannes Gredler | Sent: Thursday, July 24, 2014 15:03 | To: DECRAENE Bruno IMT/OLN; Russ White | Cc: rtgwg@ietf.org | Subject: RE: On minimizing SPF backoff induced blackouts | | hi bruno, | | IMO the problem that you're trying to solve is to have the routers still being responsive when multiple events are happening in the network. | | wouldn't then a simple fix be to kick the SPF pacing logic at a much more later point in time ? - i.e. rather than slowing down things down on event #2 or #3, do it at event # (please insert you're favorite number for ) | | /hannes | | ________________________________________ | From: rtgwg on behalf of bruno.decraene@orange.com | Sent: Thursday, July 24, 2014 20:56 | To: Russ White | Cc: rtgwg@ietf.org | Subject: RE: On minimizing SPF backoff induced blackouts | | > > I'm willing to be persuaded, I just don't see the argument for | > > specifying an algorithm with what's been put on the table to this point. | > | > Ok. So I guess my presentation/draft was not clear enough. | | Let me try again. | In slide 5: http://tools.ietf.org/agenda/90/slides/slides-90-rtgwg-2.pdf | - do we agree that it would be better if node A and B both schedule their SPF at roughly the same time? i.e. wait for the same duration? | - if so, what would be your proposition? | | Bruno | | | _________________________________________________________________________________________________________________________ | | Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. | | This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. | If you have received this email in error, please notify the sender and delete this message and its attachments. | As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. | Thank you. | | _______________________________________________ | rtgwg mailing list | rtgwg@ietf.org | https://www.ietf.org/mailman/listinfo/rtgwg | | _______________________________________________ | rtgwg mailing list | rtgwg@ietf.org | https://www.ietf.org/mailman/listinfo/rtgwg | | _________________________________________________________________________________________________________________________ | | Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc | pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler | a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, | Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. | | This message and its attachments may contain confidential or privileged information that may be protected by law; | they should not be distributed, used or copied without authorisation. | If you have received this email in error, please notify the sender and delete this message and its attachments. | As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. | Thank you. | From nobody Mon Jul 28 08:47:43 2014 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EF21B28C2 for ; Mon, 28 Jul 2014 08:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLQPVK7-M-XD for ; Mon, 28 Jul 2014 08:47:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66C71A02EB for ; Mon, 28 Jul 2014 08:47:36 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id D47EF374F08; Mon, 28 Jul 2014 17:47:34 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id B7F46180168; Mon, 28 Jul 2014 17:47:34 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 28 Jul 2014 17:47:34 +0200 From: To: Hannes Gredler Subject: RE: On minimizing SPF backoff induced blackouts Thread-Topic: On minimizing SPF backoff induced blackouts Thread-Index: AQHPqnWt5xtxZSk6LU+0XIMP0Qr3zZu1mgAA Date: Mon, 28 Jul 2014 15:47:33 +0000 Message-ID: <20194_1406562454_53D67096_20194_3087_1_53C29892C857584299CBF5D05346208A07192DEA@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <53D0FDA1.1070701@juniper.net> <10232_1406221146_53D13B5A_10232_3144_1_9E32478DFA9976438E7A22F69B08FF9205D5FF@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05b501cfa766$38872f00$a9958d00$@riw.us> <14817_1406224386_53D14802_14817_3818_1_53C29892C857584299CBF5D05346208A0718FCB6@PEXCVZYM11.corporate.adroot.infra.ftgroup> <061001cfa769$6c85b3a0$45911ae0$@riw.us> <23003_1406227762_53D15532_23003_16956_1_53C29892C857584299CBF5D05346208A0718FD7E@PEXCVZYM11.corporate.adroot.infra.ftgroup> <23003_1406228198_53D156E6_23003_17158_1_53C29892C857584299CBF5D05346208A0718FDB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <1406228599846.53663@juniper.net> <28467_1406306597_53D28925_28467_14138_1_5be0356e-4729-48ba-af44-b51fb5cd883e@OPEXCLILH05.corporate.adroot.infra.ftgroup> <20140728150718.GA17910@juniper.net> In-Reply-To: <20140728150718.GA17910@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.28.14818 Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/C_MWKjc-9vfVy8g1kPG1R-hvR2k Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: