Yakov, I am not aware of any concrete plan. Anyone? If no, let's work out a plan. The issues, which I can think of for now, needs to be addressed here are: 1. Make sure no non-private ASs (for lack of a better work) which are neigher CIDRized nor defaulting to other ASs. Existence of such AS will break the reachability of CIDR routes if individual classful net routes are replaced with CIDR routes. We need to set up a date by which we can assume all the ASs are either CIDRing and/or defaulting. 2. Gain more confidenece with the newly deployed CIDR in the networks More aggressive testing: injecting test CIDR routes to the Internet, announce it to the bgpd list along with a couple of pingable hosts in the aggregate. 3. Establish procedures for ASs to announce the replacement of individual net routes to aid the detection of potential impact/problem of removing such routes from the Internet. Andrew(?) suggested that ASs announce to the bgpd mailing list the list of individual intented to be replaced by an aggregate route several days prior to the remove. This should be a good start, shall we agree on do that? Is 3 days in advance reasonable ? --jessica Date: Thu, 10 Mar 1994 11:52:12 EST To: jyy@merit.edu cc: regional-techs@merit.edu, bgpd@merit.edu From: yakov@watson.ibm.com Subject: CIDR Return-Path: yakov@watson.ibm.com Ref: Your note of Thu, 10 Mar 1994 10:50:24 -0500 Jessica,
I believe it is still the case at the moment (test & trial stage) Are there any plans to move beyond the "test & trial stage" ? If yes, then do we have any concrete dates for when the individual networks (that form a single prefix) will be removed from the routing ?
Yakov.
1. Make sure no non-private ASs (for lack of a better work) which are neigher CIDRized nor defaulting to other ASs. Err, could you restate that? I'm having a bit of a problem parsing this. 2. Gain more confidenece with the newly deployed CIDR in the networks More aggressive testing: injecting test CIDR routes to the Internet, announce it to the bgpd list along with a couple of pingable hosts in the aggregate. Haven't we done enough of this already? I think that EVERY site should go through this phase to verify their configurations and make sure their neighbors aren't doing anything stupid, but I see no need for a site that has been CIDR-clueful for 6 months to continue pussyfooting about. 3. Establish procedures for ASs to announce the replacement of individual net routes to aid the detection of potential impact/probl of removing such routes from the Internet. Andrew(?) suggested that ASs announce to the bgpd mailing list the list of individual intented to be replaced by an aggregate route several days prior to the remove. This should be a good start, shall we agree on do that? Is 3 days in advance reasonable ? Is everyone in the world (or at least on bgpd) going to go to the trouble of checking to see if they have a -correct- aggregate route covering the individual networks and report problems if they do not? Furthermore, if they don't have the route, what tools are there in place for tracking down the lack of said route? If I'm advertising 131.108.0.0 and 131.109.0.0 and I want to replace them with 131.108.0.0/15, we can't track down the AS who is swallowing the CIDR route until we actually rip out one of the less specific routes. Given that hurdle, I suggest cutting the administriva and yanking the less specific routes at a nice slow managable rate and watching the fireworks. Then we send neutron tipped traceroutes to anyone who is still blackholing CIDR connectivity. :-)
2. Gain more confidenece with the newly deployed CIDR in the networks
More aggressive testing: injecting test CIDR routes to the Internet, announce it to the bgpd list along with a couple of pingable hosts in the aggregate.
Well, how about injecting real production CIDR routes? :-)
3. Establish procedures for ASs to announce the replacement of individual net routes to aid the detection of potential impact/problem of removing such routes from the Internet.
Andrew(?) suggested that ASs announce to the bgpd mailing list the list of individual intented to be replaced by an aggregate route several days prior to the remove.
This should be a good start, shall we agree on do that? Is 3 days in advance reasonable?
Ok, I've already broken this rule, and the roof didn't cave in, but as the people on the bgpd list saw it resulted in a connectivity problem. As soon as you-know-who (at least those on the bgpd list know) gives me an "ok" that they're ready (sometime this weekend), I will again withdraw the 129.241/16 route from the Internet, and instead rely on the 129.240/15 announcement. A host to try to ping could be eg. 129.241.1.5. Problem reports to me (yes, I've made sure your e-mail will reach me irrespective of connecitivity problems for this specific network). - Havard
participants (3)
-
Havard Eidnes -
Jessica Yu -
Paul Traina