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.