home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
- Reported by Jessica Yu/Merit
-
- Minutes of the CIDR Deployment Working Group (CIDRD)
-
-
- Agenda
-
- o Agenda changes?
- o CIDR progress report
- o Open CIDR issues
- o What is next for CIDR?
- o CIDR address allocation
-
-
- CIDR Progress Report
-
- Erik-Jan Bos and Tony Bates each presented the statistics they
- independently collected reflecting the progress of CIDR.
-
- The data shows that since the last IETF, when CIDR started to be
- deployed Internet-wide, the global routing table size decreased from
- 19758 to 18000. The number of advertised CIDR routes increased from
- 113 to 925. Jessica Yu presented data showing that the total routes
- withdrawn from the NSF/ANSNet reached about 6500 between April 94 and
- July 94. The conclusion is that CIDR has helped to reduce the growth of
- the global routing table.
-
- In the statistics presented, it is noticed that the growth of AS numbers
- is very fast from 338 in April 94 to 403 in July 94. This phenomenon
- had been discussed in the BGP Working Group meeting the previous day and
- there was an action item of writing guidelines as to when AS numbers
- should be issued.
-
-
- Open CIDR Issues
-
- o Why are some ASs still not playing?
-
- It was suggested to have a survey to those ASs in order to find
- issues which prevent them from using CIDR and to investigate
- resolutions in the working group. Jessica Yu took the action to
- conduct the survey.
-
- o What can be done to encourage them?
-
- It was suggested that service providers need to consider offering
- incentives for its attached networks to aggregate and/or renumber,
- such as giving a discount to those who do CIDR and/or are willing
- to renumber.
-
- o Is it worth it to aggregate ``old'' nets?
-
- It is agreed that aggregating ``old'' nets is still worth the
- effort since there are many existing routes which can be formed as
- a CIDR block. People should do as much as possible to aggregate
- and thus help reduce the size of the global routing table.
-
- o Larger aggregates?
-
- It was suggested that we consider aggregating routes with holes to
- increase the efficiency of aggregation, even the holes not owned by
- the aggregator. Some concerns were raised:
-
- - The AS who aggregates with holes could potentially absorb a lot
- of unwanted traffic due to the outage of the routes with longer
- masks or due to traffic to bogus destinations falling into the
- holes.
-
- - If not coordinated, it could cause routing problems.
-
- The conclusion is that an AS has to have reasonable information in
- order to do aggregation, which includes the parts that do not
- belong to itself, and has to coordinate with the ASs who ``owns''
- the block. That means that an aggregate registry is really needed.
- RIPE and Merit are working on an aggregate registry.
-
-
- What's next for CIDRD?
-
- The co-chairs raised the question of what's the next goal for CIDRD
- given CIDR is deployed. Should we just dismiss the group?
-
- The conclusion of the discussion is that there are still jobs to do in
- this working group. The new goal are:
-
-
- o Reduce the number of non-CIDR ASs
- o Find out why some ASs are still not using CIDR
- o Keep the global routing table size growth rate low, ideally to less
- than 5%
-
-
- CIDR Address Allocation
-
- Peter Ford lead the discussion of his draft document of CIDR address
- allocation. Some comments were made:
-
-
- o There needs to be further clarification of the qualification of the
- organization with IR responsibility (such as technical competence
- and financial viability).
-
- o It needs to be pointed out where the address management policy is.
- What to manage and how to manage the policy?
-
- o Technical details regarding address assignment in a CIDR
- environment need to be addressed (e.g., for a site with X number of
- hosts, how many prefixes should be allocated to the site?).
-
-
- There was a question raised as to whether this topic belongs in this
- working group. The answer is that this topic is important and needs to
- be addressed. It belongs to the Operational Requirements Area and this
- group seems to be as close as any other group to home the subject,
- especially when the technical details of the address assignment is
- addressed in the document.
-
-
-