Dear Regional Techs: We are pleased to announce that the transition from older NACR versions to the new NACR 7.0 has been smooth and successful. We would like to thank you for your excellent cooperation in this continued improvement of the NSFNET configuration process. Please let us know if there are any problems with the new template or the configuration process. Send mail to autonacr@merit.edu. This message contains a couple of announcements/clarifications about the new NACR. (1) Class C Block Submission: It is allowed to submit a block of consecutive Class C addresses in a NACR. For example, %begin nsfnet nacr v7.0 netnum: 198.4.65 - 198.4.79 netname: ICM-2 orgname: Intellicom orgaddr: 30 South First Ave. orgcity: Highland Park orgstate: NJ orgzip: 08904 orgcc: US orgtype: C bbone: T3 homeas: 701 aslist: 1:701 2:702 aup: N action: A comment: %end nsfnet nacr In this example, the ip numbers to be configured are from 198.4.65 to 198.4.79, and their names are from "ICM-2" to "ICM-16". The values for the other fields are identical. Please note that the "netname" field should be filled with the network name of the first ip address of the block (e.g., 198.4.65 in the above example). Also, in order to use this feature of the NACR, network names, as registered with the InterNIC, need to consist of a "common-prefix" and "consecutive-number" (e.g., "ICM-" and "2"), and values for the other fields must be ***identical***. Otherwise, each ip number should be submitted separately as usual. (2) CC Related AS's: The majority of the regional techs have been consistent in doing so and we really appreciate that. However, to a few requestors who have not constantly followed this rule, we ask you: please copy all related AS's when you submit a NACR to help expedite its processing. Your cooperation is really important and necessary for us to maintain the service quality as we are faced with the ever-increasing number of configuration requests. Related AS's are automatically cc'd when you use the autonacr program on merit.edu. If you haven't signed up to use the program yet, or would like to test it, please send a note to autonacr@merit.edu or call Steve Richardson at 313-747-4813. (3) Older Versions of NACR: To a couple of requestors that are still using older versions: NACR Version 7.0 is required and please do not use older versions. The new NACR template and instruction are available from nic.merit.edu: nsfnet/announced.networks/template.net.README nsfnet/announced.networks/template.net (4) "Comment" field in NACR: The "comment" field in a NACR is parsed and goes into our track system. If the comment fields extend to multiple lines, please put "comment:" at the beginning of each comment line. Thank you for your cooperation, The Merit Internet Engineering Group ps. As always, if you'd like to discuss general issues or problems with the NSFNET service, contact me directly or send mail to the list nsfnet@merit.edu which is read by several Merit managers. Mark (313) 763-6061
(1) Class C Block Submission: It is allowed to submit a block of consecutive Class C addresses in a NACR. What about Class B blocks, unlikely though such an event may be? netnum: 198.4.65 - 198.4.79 What would be allowed and not allowed here? For example: netnum: 198.4.65.0 - 198.4.79.0 should be perfectly valid, given that trailing zero part may be stripped off. But are: netnum: 198.4.65-198.4.79 netnum: 198.4.65.0-198.4.79.0 valid too? Also note that your example is a trivial one. I assume/hope you can cope with "overflows": netnum: 198.4.90-198.5.10 too? Piet
Hi, Piet: I wrote that portion and I should have it clearer. Sorry for causing the confusion. Some clarifications are inserted.
Date: Wed, 28 Jul 1993 19:27:57 +0200 From: Piet.Beertema@mcsun.EU.net To: "Mark Knopper" <mak@merit.edu> CC: regional-techs@merit.edu
(1) Class C Block Submission:
It is allowed to submit a block of consecutive Class C addresses in a NACR. What about Class B blocks, unlikely though such an event may be?
This feature is not very useful for Class B as very few sites own blocks of Class B. It is not allowed to avoid confusion and to make it easier to detect typos.
netnum: 198.4.65 - 198.4.79 What would be allowed and not allowed here? For example: netnum: 198.4.65.0 - 198.4.79.0 should be perfectly valid, given that trailing zero part may be stripped off. But are: netnum: 198.4.65-198.4.79 netnum: 198.4.65.0-198.4.79.0 valid too
All of the above are allowed. The rule is that: o The "firstip" and "lastip" should be separated by a "-" (plus zero or more white spaces). o The trailing 0 (last octet) for the "firstip" or "lastip" are optional. o Also, the first two octets of "firstip" and "lastip" have to be identical.
Also note that your example is a trivial one. I assume/hope you can cope with "overflows": netnum: 198.4.90-198.5.10 too?
Yes, such NACR's will be rejected by the parser.
Piet
-- Enke Chen Merit/NSFNET
> It is allowed to submit a block of consecutive Class C addresses > in a NACR. > What about Class B blocks, unlikely though such > an event may be? This feature is not very useful for Class B as very few sites own blocks of Class B. It is not allowed to avoid confusion and to make it easier to detect typos. Very good reason. > netnum: 198.4.65 - 198.4.79 > What would be allowed and not allowed here? > For example: > .... All of the above are allowed. Fine. Makes life easier for script-writers. ;-) The rule is that: o The "firstip" and "lastip" should be separated by a "-" (plus zero or more white spaces). o The trailing 0 (last octet) for the "firstip" or "lastip" are optional. OK, clear. o Also, the first two octets of "firstip" and "lastip" have to be identical. Ouch! See below. > Also note that your example is a trivial one. > I assume/hope you can cope with "overflows": > netnum: 198.4.90-198.5.10 > too? Yes, such NACR's will be rejected by the parser. I'm afraid I wasn't too clear this time... What I assumed/hoped was that you would cope with "overflows" in the sense that they would be treated properly, not rejected! There are perfectly valid examples of such "overflowing" blocks in the RIPE database, which is why my NACR-generating script accepts them. It didn't generate "block NACRs" though since I didn't know it was allowed; instead it breaks blocks down into separate entries. Given the risk of rejections on "overflowing" blocks I'll leave it that way. Piet
participants (3)
-
Enke Chen -
Mark Knopper -
Piet.Beertema＠mcsun.EU.net