archive-org.com » ORG » I » IEPG.ORG

Total: 69

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • IEPG Meeting - November 2002
    Daemon ppt and DISTEL ppt Daniel Karrenberg RIR presentation ppt Ray Plzak Routing Beacons and other things ppt Henk Uijterwaal GEANT Deployment of Premium IP Simon Leinen Looking at ccTLD server behaviour Nevil Brownlee Dial By ASN Bill Woodcock Sources

    Original URL path: http://www.iepg.org/november2002/index.html (2016-04-25)
    Open archived version from archive


  • IEPG Meeting - July 2002
    the Internet Car Testbeds Jun Murai RIR Update Anne Lord EBONE Postmortem Henk Uijterwaal JPNIC Study on DNS misconfiguration Akiro Kato More Bad DNS George Michaelson Analysis of RFC 1918 zones Nevil Brownlee for Andre Briodo DNS Lameness Ed Lewis

    Original URL path: http://www.iepg.org/july2002/index.html (2016-04-25)
    Open archived version from archive

  • IEPG DOCUMENT ARCHIVE
    5 2001 at Hilton London Metropole rooms 1 6 time 1000 1700 The agenda was as follows 10 00am Welcome and Introductions 10 10am Joint RIR Statistics Presentation ppt Anne Lord 10 30am APNIC x 509 ca Services and IPv6

    Original URL path: http://www.iepg.org/august2001/index.html (2016-04-25)
    Open archived version from archive

  • IEPG Minutes March 14, 1999
    together with users to find out what their perception is Questions Comments Paul Vixie ASNs might not be the best way to look at this We need smaller bucket size ie customer nets within ASNs Eg 701 spans too many continents A Agreed Ran Atkinson can you extract similar netflow data from cisco router useful alternative for Netramets to collect data Neville cisco netflow has not primarily been developed as data collecting tool it only gives summaries can t see any detailed information netramet tool doesn t also try to be a router at the same time Y2K and Root Servers Mark Kosters NSI Y2K program What is InterNIC doing wrt to Y2K history schedule which tests done root server testing contingency plans next steps other roots Summary of programme high visibility and oversight wide awareness ad participation within the organisation cross departmental teams structured methodology and independent validation Schedule Inventory all systems Assessment risk mgmt Remediation plans Test and validation Implementation Contingency planning Testing Independent test environments Multiple configurations Automated scripts full data range coverage current dates before Y2K future dates after Y2K key dates 12 special cases root NSes idea to make sure that here would be NO impact at 2000 and other dates all components of systems SW and HW wide range of tests scripts cover common query types wide range of names no problems so far key dates tests went well any date in dec 98 31 dec 98 8 sep 99 9 sep 99 etc missed the rest contingency planning risk assessment and mitigation make sure nothing will break as we go on if it would what would we do identify type impact and duration of problems before it breaks identify alternatives and triggers for alternatives full staffing on 1 Jan 2000 a Saturday what about the other root servers a number of meetings currently organised among the root name server operators Y2K is also discussed each root is independent responsible for its own testing and remediation need to examine communication scripts operating between the servers Phil NSI has a lot of resources and has put a lot of effort into this Has NSI been sharing the information with the other root name servers Mark exchange with other roots so far on an informal basis General feel is that sharing their results will be ok and will be happy to divulge what they have done Bill a lot of root name server use GPS timing and GPS rollover issue is coming up on 28 August 1999 Many people relying on GPS are issing compliance statements on this Has NSI addressed it Mark no Brian has this been discussed in the root name server advisory committee Mark yes and we will continue to do so Phil last stats slide from A root NS sustain 2 Mbps of load Are you provisioned to cope with more 6 or 7 times as mush just in case the other servers break Mark Would like to ensure that they are better provisioned even now and trying to fight that battle internally inside NSI Paul Vixie Y2K issues only a few additions all root NS are different run different operating systems routers SW etc This increases robustness against being hit by any single problem only common element is BIND only if this breaks all root NSs would break ISC has gone to the code there is no formal posting about Y2K compliance on their web site you have to be a customer so that ISC can give customers money to their insurance company F root server some other RS ops have F as 2nd point for zone transfer request after A currently have 100 Meg connection operating now at about 5Mbps sustained load Bill probably almost all root NS would be able to answer all queries they receive on 1 Jan 2000 the question is if they receive the queries the problem is not in the root NS system it is in the telephone system Spoke with US FCC May be problems in this area so FCC should prioritise circuit restoral to ensure that root server system can get reconnected into infrastructure Paul ensures that the NS operators have loads of experience to operate root NS system even with half the servers down Internet doesn t stop to work it just gets a little slower ARIN status report Michael O Neill Overview registration stats and services news from arin membership details meeting coming up stats for Jan Feb 1999 24s issued to ISPs 3496 3128 24s issued to end users 80 48 ASN s issued 74 110 approved 110 118 ASNs pending 58 159 IP requests rejected 4 2 IP addresses transfers 13 8 new ISP requests 87 96 new IP requests 45 27 first time allocs to ISPs 22 39 of those multihomed policies 9 17 rejected ISP requests n a 3 ISPs receiving allocation 46 57 number of allocations to ISP members in 1998 small 24 19 227 medium 18 16 183 large 15 14 32 XLarge 14 7 news new initiatives new policies ARIN now issues 20s and shorter prefixes everyone else has to go to their upstream ISP multi homed policy remains unchanged demonstrate efficient use of 21 registration of 20 can be made must have prefixes announced by at least 2 of their upstreams agree to renumber ARIN routing registry launched on 8 Feb 99 documentation on http www arin net rr stats since launch 6 maintainer objects 3 aut num objects 10 objects in total IPv6 first IPv6 templates forms being tested testing whois with IPv6 support registration services tests allocations reassignments modifications of subTLA registrations ARIN staff introductions Shane Kerr Nathan David ARIN membership meeting Atlanta Georgia 12 13 April first day working group meetings for the first time routing registry grandfathered IP registration Rwhois Swip ARIN database second day plenary meeting URLs Membership http www arin net membership html Current members https members arin net Questions Paula is it a requirement to register

    Original URL path: http://www.iepg.org/march1999/index.html (2016-04-25)
    Open archived version from archive

  • IEPG Minutes Dec 6 1998
    of Qwest presented a few statistics from the routing registries related to IPv6 registrations Dec 1st Aug 20 ipv6 site 332 302 inet6num 201 175 person 374 326 role 24 21 mntnr 113 98 3 ARIN Ramin Rad Stats are available from http www arin net IPStats html A few selected entries HTTP Jun Dec 8M hits 47K hits day 2 7M WHOIS queries Projects RWHOIS completed and running DNS for in addr arpa in testing Projects underway more automation routing registry IPv6 registry rewrite basic system Ingres Oracle increase redundancy of servers Routing registry issues testing RADB derivative of RIPE DBv2 RPSL capable Modified to use Oracle Will eventually support PGP Looking at other software BIRD IPv6 issues Store full address including interface ID Suggestion not codify current practice but have option to store full address to cater for still undefined formats next version of RFCs etc inet6num RIPE object for internal data representation Use it for external representation too Not yet decided Rewrite of internal system Better UI for internal users Super WHOIS for external use embed references using HTML etc More automation and improve turn around Q A How many blocks for ARIN in in addr arpa 12 The rest of the zone data for the addresses ARIN maintains will remain in in addr arpa 4 CAR experiences or why I don t want a CAR but a TRUCK Ran Atkinson Home Ran gave a presentation based on the slides made and shown earlier at NANOG by Cathy Wittbrodt CAR does packet classification and rate limiting implemented with a simple token bucket characterized by average rate bps normal burst bytes extended burst bytes actually normal extended Actions transmit drop mark A lab setup was used during the tests the object being to limit the access rate of a customer to something below the physical access rate The normal burst setup caused a lot of retransmits knee in curve at 24KB burst size at 128kbit s it caused approximately 20 retransmits A TCP sequence time plot showed a distinct stair step with short bursts and long periods for time outs associated with packet loss Throughput was xxx kbit s Another setup used shaping with an ATM PVC which showed unsurprisingly quite an improvement Generic traffic shaping also improved the situation although there are still issues with performance of that code VIP2 load fast switching vs distributed packet switching etc Yet another test setup made use of the extende burst settings and the results looked similar to the normal burst test although retransmits were reduced to approx 7 With multiple parallel streams over a CAR path the TCPs showed distinct tendencies to self synchronization leading to low throughput A few formulas had been worked out to suggest optimal settings of the CAR parameters bn r 1 8 1 5s be bn r 1 8 1 5s 2 x bn Home had also used CAR in the field on a busy 7500 with FDDI There were essentially no big surprises

    Original URL path: http://www.iepg.org/december1998/index.html (2016-04-25)
    Open archived version from archive

  • June 1996 IEPG Meeting
    IANA an experimental deployment of 2 additional name servers with proposed locations in the UK Linx and Japan WIDE Project and proposed timing duration and objectives of the experiment to be documented Action Bill Manning Global Caching Hierarchy Dale Wessels lead an examination of the aspects of caching web traffic URL is http www nlanr net Cache The trade offs includes the advantages offered by caching of high local bandwidth access low latency improved load management and greater robustness of access to the cache balanced against risk factors of loss of direct hit counts and loss of client identity from the server both marketing driven features of many web pages failure modes which are not user definable the requirements for manual user configuration stale cache data concentration of single failure points and the opening of security peepholes and introduction of the capability to undertake third party access restrictions SQUID is an outcome of the Harvest activity and uses the Internet Cache Protocol ICP which implements a cache proxy protocol using a hierarchy of cache servers and adaptive cache referral mechanisms which take RTT into account together with total elapsed query time The current deployment of SQUID servers includes 6 NLANR servers in operation on the vBNS using 128Mb DEC Alpha platforms with 8G disk subsystems with a forced 3 day TTL within the cache using a single process implementation of the cache server Scaling is being examined with the current servers experiencing 10 15 load levels while servicing 100 000 200 000 requests per day Other issues relevant to the scaling of caches include cache friendly resources cache hit referrals to the original source and copyright and liability issues Cache hits rates are noted at 15 20 within the hierarchy but this increases to 35 40 at the user facing edge of the cache system Traffic Flow Analysis Nevil Brownlee reported on further work using the NeTraMet network monitoring base with adaptation to allow the metering architecture to track single sessions defined by a Protocol sourceIP sourcePort destIP destPort 5 tuple examining the number of packets bytes bytes second and duration of observed flows This presentation was an overview of the work being undertaken in the IETF RTFM Working Group and further information can be found at http www auckland ac nz net Internet rtfm TOP html Settlement Metrics Brian Carpenter introduced a draft paper concerning inter provider settlement metrics ftp dxcoms cern ch pub tmp bc metrics ps As usual this topic generated large volumes of comment and a wide range of views ranging from the view that this problem which required common formal settlement structures through to informal settlement through content brokerage Phone settlement structures were noted and the IETF IPPM work was also noted as well as Brian s work in attempting to define a language set and associated metrics which could be applicable to inter provider settlements The group did highlight that issue that inter provider settlement structures if they become widely adopted will have a

    Original URL path: http://www.iepg.org/june1996/index.html (2016-04-25)
    Open archived version from archive

  • IEPG Meeting - March 1996
    where one of his name servers had been delegated to but which he had never heard of much less configured in his name servers A point was made that two separate name servers for each zone may not be enough and a painful experience was cited when a primary was down for a long time and the single secondary was down for a short This is possibly fodder for a new I D It was mentioned that InterNIC is currently tightening their requirements for technical correctness before delegating and that the RIPE NCC and APNIC are already checking the data before delegating although RIPE NCC and APNIC only handle in addr arpa domains 4 Draining 192 8 Draining the swamp This is an effort undertaken to get people to voluntarily return address space in 192 8 and either renumber into private address space or into more aggregateable address space The InterNIC data was used to try to contact people and of the 6000 requests sent 1500 failed and only 1800 responded David Conrad from APNIC commented that this wasn t too surprising and that they typically have approximately 85 failure rate due to stale data An overview of the currently active routes in this address space can be found in http www isi edu div7 pier whose routes Peter Lothberg commented that giving back IP addresses within 192 8 might be a problem since some registries appear to insist on having a customer relationship with the party giving back the addresses the RIPE NCC was mentioned Mike O Dell commented that the process of keeping the registry data up to date is fundamentally broken since we are using humans to keep track of what is essentially computer data and that some improvement to this process should be possible A suggestion for other targets to perform similar activities in was mentioned e g 198 8 and 204 8 5 IP address registry issues Randy Conrad from the APNIC made a presentation about the formal organization of the IP address registries The historic model is a hierarchy US DoD FNC IANA InterNIC RFC 1466 introduced RIPE NCC and APNIC as clients of the InterNIC This model is as it s name indicates historical and will probably not continue The new so called politically correct model is a hierarchy ISOC IAB IANA with InterNIC RIPE NCC and APNIC as all answering to IANA and still with no end users directly as clients of the regional registries This is the likely future A more pragmatic model would change the top of the hierarchy in the PC model to have the IANA answer to the ISPs This binding currently does not exist This model is slightly unstable in that it lacks end user representation A couple of comments o IPv4 address space is becoming more scarce and more valuable However it s not as scarce as route slots o Registries can t modify their policies by ISP whims o The end of unallocated free address

    Original URL path: http://www.iepg.org/march1996/index.html (2016-04-25)
    Open archived version from archive

  • July 1995 IEPG Meeting
    put in as a bonus item waiting for lunch thanks David David Conrad reports that there are a few layer 2 interconnects in the AP region Examples include HKIX Hong Kong Internet Exchange ethernet exchange in Hong Kong where some 25 to 30 service providers are present STIX Singapore TelCo Internet Exchange Interconnect for Vietnam and many other countries in the region 8 Charging models settlements costs Political issues engineering impact Sean Doran explains that SprintLink sees a growth of 20 per month and that US Sprint s competitors are seeing roughly the same How do we keep up with this growth Some routers of SprintLink are running at half capacity e g in terms of switching capacity Within around 6 months there will be no boxes available to keep up with the growth Four areas are crucial Technical We need a box that can accomodate the growth for the years to come SprintLink talks to switch routers to develop a BFR some say this means Big Fine Router your mileage may vary Line capacity is also a worry experiments with IP over SONET are taking place Capacity at exchange points is a worry The general feeling is that the capacity of an exchange point should be an order of magnitude faster than the incoming lines multiple exchange points often can imply asymmetry Addressing Comes back to CIDRD basically Exhaustion of the IP address space is imminent but how soon will this happen Scaling these issues are becoming tough Training NOCs sometimes are not up to skills Training people is not to be underestimated Multi homed There is a tendency for customers of one provider to become multi homed through another provider Knowledge Knowing what is going on There are a lot of people that are not coming to meetings like the IEPG or read e mail Money Vertical integration Companies doing everything from running a backbone to dial in IP service Some providers start as a backbone provider and now have to do dial also Or the other way around a provider that starts up as a dial in provider Politics A lot of politics is coming in This creates inefficiency The engineers busy with the technology have spent too less time educating the politicians The real issue How do we go by fixing this People need to educate the politicians to do the right thing Some decisions have great political implications but are hairy to implement Peter Lothberg explains how the phone companies do charging Phone company A and B want to interconnect and both buy a HC to each other A phonecall originating within a customer of A to a customer of B also makes money flow in the direction from A to B The conclusion on this is that this is a great model for the connection oriented world Sean Doran explains a model where there are different levels of service provision Dial in providers for end user support Mid level providers regionals for dial in provider support and large customer support International providers support for the regionals Sean states that international providers should not want to enter any of the other levels vertical approach which more often than not means competition to your customers Tony Bates warns that this model may be fine for SprintLink but not necessary for other companies The model of wholesalers and retailers works well in other industries Sean Doran promises to make a document out of all this The discussion leads to multi homing Why would an organization want to be multi homed Possible carrots are economics resilience or reliability Two issues are brought up WRT multi homing what does multi homing do to the address space what does it do for the routing Often one problem with multi homing is explaining it to people And besides there are different flavors of multi homing 9 Dual homing in a CIDR block Prologue NAT boxes are not considered in this agenda item Yakov Rehkter addresses the issues of multi homing in a CIDR block by first explaining the issues Use of AS number Each multi homed site should have its own AS number The question is Can private AS numbers be used Each multi homed site should use BGP to peer with its providers since this allows dynamic rerouting There is a draft document draft ietf idr autosys guide 03 txt One prefix One origin AS A given prefix can reside in only one AS If you have aggregation this can be violated example when a multi homed site has address space from one of his providers this provider will advertise the prefix of the block from his AS the other provider of the customer will announce the prefix from the customers ASN Each prefix has to have a unique origin Aggregation AS SET may create some confusion to this principle Path preferences Need the ability to influence upstream providers when multiple paths are available Multiple interconnects with direct provider one should be using MEDs Multiple paths to some indirect upstream provider known as AS stuffing Need to have a mechanism to specify destination preferences two Internet Drafts draft ietf idr bgp dpa 01 txt draft ietf idr bgp dpa application 01 txt There is an idea for a New BGP Attribute which works with the existing route selection attributes such as MED and Local Pref Issues regarding Address Allocation We need to look at the impact on aggregation Multiple addresses one per provider which is very good for scaling but not practical today Address from one of the providers which provider to select where the aggregation could occur The idea is Get your address space from your least preferred provider so only your preferred provider needs to announce this prefix and for your back up provider it falls into his CIDR block Provider independent address this is however the worst case for getting scaling issues right Routing Information Aggregation There is a growth in the number of multi homed subscribers

    Original URL path: http://www.iepg.org/july1995/index.html (2016-04-25)
    Open archived version from archive



  •