From epg at merit.edu Fri Sep 2 17:55:35 1994 From: epg at merit.edu (epg at merit.edu) Date: Fri, 2 Sep 1994 11:55:35 -0400 (EDT) Subject: Draft of RIPE81++ In-Reply-To: <199408262059.QAA22837@merit.edu> from "Jessica Yu" at Aug 26, 94 04:59:41 pm Message-ID: <9409021555.AA00496@pepper.merit.edu> Daniel, Marten, and Tony, We'd like to discuss three parts of the draft prior to the RIPE meeting in Portugal. They are: 1) the mandatory nature of the gateways in the interas attribute 2) the mandatory nature of asin/out attributes if interas attributes are present 3) the proposal for an asname attribute 4) the proposal for a change time attribute 1) the mandatory nature of the gateways in the interas attribute We are concerned that requiring the identification of the local gateway and the remote gateway in the interas attribute has two problems. The first problem is that of maintenance of the attribute. If an AS is required to list both the local gateway and the remote gateway, then the AS must update its registry information whenever the remote AS makes any configuration changes. This could lead to many inconsistencies within the database. The second issue is that by permitting ASs to just register information about a local gateway is in keeping with the principle of only entering local information in the registry. If an AS wants to indicate a local preference for a gateway independent of information about another ASs border routers, that seems in keeping with the underlying philosophy of the routing registry. We suggest that making the listing of a pair of gateways mandatory will lead to inconsistencies in the registry and therefore it should remain optional. However, we do realize that permitting the registration of 0, 1 or 2 gateways with the proposed syntax can lead to ambiguity. Is there a way that we can leave the gateway statements as optional and clarify the ambiguity business? For instance, there are several ways to clarify this ambiguity. For instance we could simply declare that if there is one gateway, it is the local one. There are also easy syntax change options, such as allowing the token "-" to stand for one or both of the gateways to eliminate ambiguity. We were in agreement until a few weeks ago that these would be optional and to make them mandatory simply to resolve a syntax problem when other solutions are available is a loss 2) the mandatory nature of asin/out attributes if interas attributes are present There are three reasons that we oppose making asin/out mandatory conditional on whether there is an interas attribute specified. First of all, asin/out attribute is just a subset of the interas attribute; therefore the requirement to repeat information from the interas attribute in the asin/out attribute is redundant. It brings no added information to the registry. Secondly, there are cases where the information in the asin/out attribute will not clearly reflect the interas information, thereby presenting inconsistent information in asin/out and interas. The example of this is: interasin: from 690:1 lgateway1 rgateway accept 237 interasin: from 690:3 lgateway2 rgateway accept 237 So if the user is required to register an asin attribute, what do they choose? Whatever the choice it will reflect acceptance of AS 237 by AS 690, but the preference will be inconsistent with the information described in interas. Finally, by making asin/out mandatory with the use of the interas attribute, we increase our chances of introducing discrepancies into the registry whenever modifications are made to the registry. Any updates that are made to an AS's information must be repeated in both attributes. Therefore we propose that the asin/out attribute and the interas attribute should remain optional and uncoupled. We propose that users should be able to use none, one or both to describe their local routing policy. 3) the proposal for an asname attribute It seems reasonable to add an asname attribute because it will simplify server client requests and is used explicitly by some tools. Just as netnames for IP addresses have proved useful and are often listed independently, we think that it would be useful to have an attribute which is explicitly for AS names. For example, the "AStrace" tool explicitly uses this information and AS names have proven useful in much of our PRDB work. 4) the proposal for a change time attribute The suggestion to add an attribute which automatically appends the time stamp of the change to that attribute seems like a simple modification and one that would provide another indication as to how current information is. If someone were to check the registry twice in one day for information, and the information had been modified more than once that day, the time stamp would indicate that. Also, there is a small chance that modifications might arrive out of order due to network problems and the time stamp would be a good way to insure that older information does not override current information. The change time attribute is another useful bit of information if we need to do any problem diagnostics and it doesn't require any dramatic changes to the registry. Just as you all would, we would like to settle these little issues as soon as possible so that the document can be accepted at the RIPE meeting. We appreciate how difficult some of these discussions have been, but we are just as anxious as you to move ahead and get this implemented and operational. --Elise -------- Logged at Mon Sep 5 14:01:07 MET DST 1994 --------- From Tony.Bates at ripe.net Mon Sep 5 14:01:04 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Mon, 05 Sep 1994 14:01:04 +0200 Subject: Draft of RIPE81++ In-Reply-To: Your message of Fri, 02 Sep 1994 11:55:35 EDT. <9409021555.AA00496@pepper.merit.edu> Message-ID: <9409051201.AA14700@mature.ripe.net> epg at merit.edu writes: * * Daniel, Marten, and Tony, * * We'd like to discuss three parts of the draft prior to the * RIPE meeting in Portugal. They are: * Okay...here are my comments below. * 1) the mandatory nature of the gateways in the interas attribute * * We are concerned that requiring the identification of the local * gateway and the remote gateway in the interas attribute has two * problems. The first problem is that of maintenance of the attribute. * If an AS is required to list both the local gateway and the remote * gateway, then the AS must update its registry information whenever * the remote AS makes any configuration changes. This could lead * to many inconsistencies within the database. * But surely by its very nature the attribute is a two way attribute and we want to encourage people to update when they make a configuration change. This is meant to contain this information. Also, what is the semantic of just registering your own side anyway. How is one supposed to work out the other side if you have multiple connections to an AS. * The second issue is that by permitting ASs to just register information * about a local gateway is in keeping with the principle of only entering * local information in the registry. If an AS wants to indicate * a local preference for a gateway independent of information about * another ASs border routers, that seems in keeping with the underlying * philosophy of the routing registry. * Perhaps, but this is somewhat double edged as you also want to see the ability to just (as it is optional) register the remote gateway as well which appears to contradict both above points. * We suggest that making the listing of a pair of gateways mandatory * will lead to inconsistencies in the registry and therefore it * should remain optional. However, we do realize that permitting * the registration of 0, 1 or 2 gateways with the proposed syntax * can lead to ambiguity. * I dont agree on the inconsistencies. The type of people who will use this attribute will know what their peers AS routers are. Lets face it who runs there BGP peering without configuring the remote peer address? * Is there a way that we can leave the gateway statements as optional * and clarify the ambiguity business? For instance, there are several * ways to clarify this ambiguity. For instance we could simply declare that * if there is one gateway, it is the local one. There are also easy * syntax change options, such as allowing the token "-" to stand for * one or both of the gateways to eliminate ambiguity. * Sure but this is not mandatory for solving the ambiguity. * We were in agreement until a few weeks ago that these would be optional * and to make them mandatory simply to resolve a syntax problem when * other solutions are available is a loss * Well perhaps it may have seen that way but this is probably due to me copying in Jessicas text without checking properly. When discussed here and with John-Micheal we would like to keep this mandatory. I truly believe porviders will know both ends of their peering and are as likely to update both address as much as they are to use this attribute and update other policy information. * 2) the mandatory nature of asin/out attributes if interas attributes are * present * * There are three reasons that we oppose making asin/out mandatory * conditional on whether there is an interas attribute specified. * * First of all, asin/out attribute is just a subset of the interas * attribute; therefore the requirement to repeat information from * the interas attribute in the asin/out attribute is redundant. It * brings no added information to the registry. * Sure - but for many they will use and understand the as-in/as-out attrbiute. So it is an extras line of information but represents the global routing policy. * Secondly, there are cases where the information in the asin/out * attribute will not clearly reflect the interas information, thereby * presenting inconsistent information in asin/out and interas. The * example of this is: * * interasin: from 690:1 lgateway1 rgateway accept 237 * interasin: from 690:3 lgateway2 rgateway accept 237 * * So if the user is required to register an asin attribute, what * do they choose? Whatever the choice it will reflect acceptance * of AS 237 by AS 690, but the preference will be inconsistent * with the information described in interas. * No not at all - at the AS level this is totally correct. If I am AS99 I dont care about the interactions of between AS690 gateways, only that it accepts routes for AS237 * Finally, by making asin/out mandatory with the use of the interas * attribute, we increase our chances of introducing discrepancies * into the registry whenever modifications are made to the registry. * Any updates that are made to an AS's information must be * repeated in both attributes. * Yep - the fact remains though that extra information will be minimal, will make it clearer for some - this was expressed at the RIPE meeting. * Therefore we propose that the asin/out attribute and the interas * attribute should remain optional and uncoupled. We propose * that users should be able to use none, one or both to describe * their local routing policy. * Well I think the only thing we can do on these two points is put both arguments to RIPE routing group at the RIPE meeting and let them decide. * 3) the proposal for an asname attribute * * It seems reasonable to add an asname attribute because it * will simplify server client requests and is used explicitly * by some tools. Just as netnames for IP addresses have proved * useful and are often listed independently, we think that it * would be useful to have an attribute which is explicitly * for AS names. For example, the "AStrace" tool explicitly uses * this information and AS names have proven useful in much of our PRDB work. * I think this is a good thing to do as well. I am going to add this into the text later today. I will leave in description as well. One problem we have in terms of backward compatability is I will have to make AS name optional. Is this going to cause you a lot of heart burn otherwise we have yet another tranisition to do. * 4) the proposal for a change time attribute * Firstly, as said before this is totally outside the context of RIPE-81++. I know what the suggestion is and has already been put by Laurent to the DB wg. As far as I remember it was deemed "not worth doing" by the chair. Please send a message about this again if you want to see any progress on this I would say. --Tony. -------- Logged at Tue Sep 6 15:11:43 MET DST 1994 --------- From jimi at dxcoms.cern.ch Tue Sep 6 15:11:33 1994 From: jimi at dxcoms.cern.ch (Jean-Michel Jouanigot) Date: Tue, 6 Sep 1994 15:11:33 +0200 (MET DST) Subject: Draft of RIPE81++ In-Reply-To: <9409051201.AA14700@mature.ripe.net> from "Tony Bates" at Sep 5, 94 02:01:04 pm Message-ID: <9409061311.AA29253@dxcoms.cern.ch> Elise, Tony & al. >----- Text sent by Tony Bates follows ------- > epg at merit.edu writes: > * > * 1) the mandatory nature of the gateways in the interas attribute > * > * We are concerned that requiring the identification of the local > * gateway and the remote gateway in the interas attribute has two > * problems. The first problem is that of maintenance of the attribute. > * If an AS is required to list both the local gateway and the remote > * gateway, then the AS must update its registry information whenever > * the remote AS makes any configuration changes. This could lead > * to many inconsistencies within the database. > * > But surely by its very nature the attribute is a two way attribute and > we want to encourage people to update when they make a configuration > change. This is meant to contain this information. Also, what is the > semantic of just registering your own side anyway. How is one supposed > to work out the other side if you have multiple connections to an AS. > > * The second issue is that by permitting ASs to just register information > * about a local gateway is in keeping with the principle of only entering > * local information in the registry. If an AS wants to indicate > * a local preference for a gateway independent of information about > * another ASs border routers, that seems in keeping with the underlying > * philosophy of the routing registry. > * > Perhaps, but this is somewhat double edged as you also want to see the > ability to just (as it is optional) register the remote gateway as > well which appears to contradict both above points. > > * We suggest that making the listing of a pair of gateways mandatory > * will lead to inconsistencies in the registry and therefore it > * should remain optional. However, we do realize that permitting > * the registration of 0, 1 or 2 gateways with the proposed syntax > * can lead to ambiguity. > * > I dont agree on the inconsistencies. The type of people who will use > this attribute will know what their peers AS routers are. Lets face it > who runs there BGP peering without configuring the remote peer address? > > * Is there a way that we can leave the gateway statements as optional > * and clarify the ambiguity business? For instance, there are several > * ways to clarify this ambiguity. For instance we could simply declare that > * if there is one gateway, it is the local one. There are also easy > * syntax change options, such as allowing the token "-" to stand for > * one or both of the gateways to eliminate ambiguity. > * > Sure but this is not mandatory for solving the ambiguity. > > * We were in agreement until a few weeks ago that these would be optional > * and to make them mandatory simply to resolve a syntax problem when > * other solutions are available is a loss > * > Well perhaps it may have seen that way but this is probably due to me > copying in Jessicas text without checking properly. When discussed > here and with John-Micheal we would like to keep this mandatory. I > truly believe porviders will know both ends of their peering and are > as likely to update both address as much as they are to use this > attribute and update other policy information. When I proposed together with Tony to put this attribute mandatory, I would not have thought that we would create a revolution :-) Elise, I agree with you, there's no need to register information you don't need, it's more difficult to manage, but as Tony points out, why would anybody need this detailed information unless you really want to configure a box with it, in which case you *need* the local and remote addresses. Well, I don't know the answer, but you probably have such a case, otherwhise you would not ask for it :-) What I would propose is to: 1- Keep the ordering as it is in Ripe-81++ (to be close to the as-in syntax), 2- Accept the Local and remote router info to be optional 3- Solve the parsing issue by adding what Jessica proposed (L:... R:...) Well, I'm not sure I do agree with what I write, but if I can get a consensus ... > * 2) the mandatory nature of asin/out attributes if interas attributes are > * present > * > * interasin: from 690:1 lgateway1 rgateway accept 237 > * interasin: from 690:3 lgateway2 rgateway accept 237 > * > * So if the user is required to register an asin attribute, what > * do they choose? Whatever the choice it will reflect acceptance > * of AS 237 by AS 690, but the preference will be inconsistent > * with the information described in interas. > * > No not at all - at the AS level this is totally correct. If I am AS99 > I dont care about the interactions of between AS690 gateways, only > that it accepts routes for AS237 Tony, the question is not answered, Elise is right. This AS will have a line like as-in: from AS690 ?? accept 237 since as-in IS mandatory. What pref should I use? *I* have no answer to this one! > > * Finally, by making asin/out mandatory with the use of the interas > * attribute, we increase our chances of introducing discrepancies > * into the registry whenever modifications are made to the registry. > * Any updates that are made to an AS's information must be > * repeated in both attributes. > * > Yep - the fact remains though that extra information will be minimal, > will make it clearer for some - this was expressed at the RIPE > meeting. > > * Therefore we propose that the asin/out attribute and the interas > * attribute should remain optional and uncoupled. We propose > * that users should be able to use none, one or both to describe > * their local routing policy. > * > Well I think the only thing we can do on these two points > is put both arguments to RIPE routing group at the RIPE meeting and > let them decide. Interasin will give details on as-in. There's several ways to remove the dupplication of information: 1- If interasin is present, as-in is refused (berk!) 2- put interasin and as-in optional, but how about a policy without any interasin nor as-in ? ;-) Personnaly, I don't think that the majority of the policies will use the interasin and I would prefer to keep the dupplication of information by keeping as-in and interasin (with as-in mandatory, and interasin optional), providing we can find a solution to preference issue in as-in... > * 3) the proposal for an asname attribute > * > * It seems reasonable to add an asname attribute because it > * will simplify server client requests and is used explicitly > * by some tools. Just as netnames for IP addresses have proved > * useful and are often listed independently, we think that it > * would be useful to have an attribute which is explicitly > * for AS names. For example, the "AStrace" tool explicitly uses > * this information and AS names have proven useful in much of our PRDB work. > * > I think this is a good thing to do as well. I am going to add this > into the text later today. I will leave in description as well. One > problem we have in terms of backward compatability is I will have to > make AS name optional. Is this going to cause you a lot of heart burn > otherwise we have yet another tranisition to do. I support this as well. > * 4) the proposal for a change time attribute > * > Firstly, as said before this is totally outside the context of > RIPE-81++. I know what the suggestion is and has already been put by > Laurent to the DB wg. As far as I remember it was deemed "not worth > doing" by the chair. Please send a message about this again if you > want to see any progress on this I would say. I also support this, and I will discuss it with Wilfried. -- Jean-Michel -------- Logged at Tue Sep 6 22:56:11 MET DST 1994 --------- From epg at merit.edu Tue Sep 6 22:52:44 1994 From: epg at merit.edu (epg at merit.edu) Date: Tue, 6 Sep 1994 16:52:44 -0400 (EDT) Subject: Draft of RIPE81++ In-Reply-To: <9409061311.AA29253@dxcoms.cern.ch> from "Jean-Michel Jouanigot" at Sep 6, 94 03:11:33 pm Message-ID: <9409062052.AA00991@pepper.merit.edu> Jean-Michel and Tony, Thanks for your comments. Let me preface my following responses with a probably contentious statement (though I'm not looking for an argument nor trying to start a fight) - we probably wouldn't be having this debate if we had just modified as-in and as-out to optionally include multi-exit discriminators. Then there would be no need for interas-in and interas-out and there would be no need to translate from interas-in/out to as-in/out. But I acknowledge that you all do not want to modify as-in/out and therefore if we are to support multi-exit discriminators, we need to have a new attribute. Just wanted to say that because as I responded to all this, it seemed to me that we were trying to refine a kludge instead of focusing on what we had started out to describe. Probably just grumpy 'cause it's a nice day and I'm stuck inside. So now for the responses to your responses.... >-----------------------Jean-Michel writes------------------ > > Elise, Tony & al. > > >----- Text sent by Tony Bates follows ------- > > epg at merit.edu writes: > > * > > * 1) the mandatory nature of the gateways in the interas attribute > > * > > * We are concerned that requiring the identification of the local > > * gateway and the remote gateway in the interas attribute has two > > * problems. The first problem is that of maintenance of the attribute. > > * If an AS is required to list both the local gateway and the remote > > * gateway, then the AS must update its registry information whenever > > * the remote AS makes any configuration changes. This could lead > > * to many inconsistencies within the database. > > * > > But surely by its very nature the attribute is a two way attribute and > > we want to encourage people to update when they make a configuration > > change. This is meant to contain this information. Also, what is the > > semantic of just registering your own side anyway. How is one supposed > > to work out the other side if you have multiple connections to an AS. > > Guess, our thoughts on this are colored by working with folks like BARRNET which have always had at least two gateways that peer with our one gateway. BARRNET has then preferred to accept one set of nets at one router and the rest of the nets at another router. > > * The second issue is that by permitting ASs to just register information > > * about a local gateway is in keeping with the principle of only entering > > * local information in the registry. If an AS wants to indicate > > * a local preference for a gateway independent of information about > > * another ASs border routers, that seems in keeping with the underlying > > * philosophy of the routing registry. > > * > > Perhaps, but this is somewhat double edged as you also want to see the > > ability to just (as it is optional) register the remote gateway as > > well which appears to contradict both above points. > > > > * We suggest that making the listing of a pair of gateways mandatory > > * will lead to inconsistencies in the registry and therefore it > > * should remain optional. However, we do realize that permitting > > * the registration of 0, 1 or 2 gateways with the proposed syntax > > * can lead to ambiguity. > > * > > I dont agree on the inconsistencies. The type of people who will use > > this attribute will know what their peers AS routers are. Lets face it > > who runs there BGP peering without configuring the remote peer address? > > Whereas someone will always configure their peer router, we're not convinced that folks will show the same attention to updating the routing registry. > > * Is there a way that we can leave the gateway statements as optional > > * and clarify the ambiguity business? For instance, there are several > > * ways to clarify this ambiguity. For instance we could simply declare that > > * if there is one gateway, it is the local one. There are also easy > > * syntax change options, such as allowing the token "-" to stand for > > * one or both of the gateways to eliminate ambiguity. > > * > > Sure but this is not mandatory for solving the ambiguity. > > Whoops, maybe I had a wrong assumption here. It seemed to me that the local and remote gateway characteristics of the interas-in/out attribute had been changed to mandatory (whereas they used to be optional) because with the selected syntax listing one gateway only would be ambiguous. Listing no gateways or two gateways is unambiguous; it's only if you are permitted to list only one gateway that there is no way to distinguish whether it is a local gateway or a remote gateway. Have I made the incorrect assumption? > > * We were in agreement until a few weeks ago that these would be optional > > * and to make them mandatory simply to resolve a syntax problem when > > * other solutions are available is a loss > > * > > Well perhaps it may have seen that way but this is probably due to me > > copying in Jessicas text without checking properly. When discussed > > here and with John-Micheal we would like to keep this mandatory. I > > truly believe porviders will know both ends of their peering and are > > as likely to update both address as much as they are to use this > > attribute and update other policy information. > > When I proposed together with Tony to put this attribute > mandatory, I would not have thought that we would create a > revolution :-) > Elise, I agree with you, there's no need to register information > you don't need, it's more difficult to manage, but as Tony points > out, why would anybody need this detailed information unless you > really want to configure a box with it, in which case you *need* > the local and remote addresses. Well, I don't know the answer, > but you probably have such a case, otherwhise you would not ask > for it :-) What I would propose is to: > > 1- Keep the ordering as it is in Ripe-81++ (to be close to the > as-in syntax), > OK > 2- Accept the Local and remote router info to be optional > OK > 3- Solve the parsing issue by adding what Jessica proposed (L:... R:...) > OK > Well, I'm not sure I do agree with what I write, but if I can get a > consensus ... > > > * 2) the mandatory nature of asin/out attributes if interas attributes are > > * present > > * > > * interasin: from 690:1 lgateway1 rgateway accept 237 > > * interasin: from 690:3 lgateway2 rgateway accept 237 > > * > > * So if the user is required to register an asin attribute, what > > * do they choose? Whatever the choice it will reflect acceptance > > * of AS 237 by AS 690, but the preference will be inconsistent > > * with the information described in interas. > > * > > No not at all - at the AS level this is totally correct. If I am AS99 > > I dont care about the interactions of between AS690 gateways, only > > that it accepts routes for AS237 > > Tony, the question is not answered, Elise is right. This AS will have a line > like > > as-in: from AS690 ?? accept 237 > > since as-in IS mandatory. What pref should I use? *I* have no answer to this > one! > My assumption is that since neither as-in/out nor interas-in/out are mandatory attributes within the aut-num object, it is unnecessary to mandate a corresponding as-in/out attribute if there is an interas-in/out attribute specified. The policy expressed in the aut-num object should be the union of the as-in/out and interas-in/out statements. I think that we (both Merit and RIPE) have artifically added this complexity because we all compromised on the way we added the multi- discriminator information by creating a new attribute. Since we have done this, we should try to avoid mandating a situation which will knowingly misrepresent registered information. > > > > * Finally, by making asin/out mandatory with the use of the interas > > * attribute, we increase our chances of introducing discrepancies > > * into the registry whenever modifications are made to the registry. > > * Any updates that are made to an AS's information must be > > * repeated in both attributes. > > * > > Yep - the fact remains though that extra information will be minimal, > > will make it clearer for some - this was expressed at the RIPE > > meeting. > > > > * Therefore we propose that the asin/out attribute and the interas > > * attribute should remain optional and uncoupled. We propose > > * that users should be able to use none, one or both to describe > > * their local routing policy. > > * > > Well I think the only thing we can do on these two points > > is put both arguments to RIPE routing group at the RIPE meeting and > > let them decide. > > Interasin will give details on as-in. There's several ways to remove the > dupplication of information: > > 1- If interasin is present, as-in is refused (berk!) > 2- put interasin and as-in optional, but how about a policy without any > interasin nor as-in ? ;-) > Jean-Michel, as-in/out has never been mandatory - at least from my reading of the documents. So folks could previoulsy register an aut-num without registering any policy. If we want to mandate that folks have to register policy in aut-num; then that is a different reason to make as-in/out mandatory. But in that case mandating either as-in/out or interas-in/out would suffice to meet the requirement. Since as-in/out has never been mandatory, I do not understand why it should be mandatory if someone chooses to register interas-in/out. > Personnaly, I don't think that the majority of the policies will > use the interasin and I would prefer to keep the dupplication of > information by keeping as-in and interasin (with as-in mandatory, > and interasin optional), providing we can find a solution to > preference issue in as-in... > Repeat, of my previous comment - as-in has never been mandatory. > > * 3) the proposal for an asname attribute > > * > > * It seems reasonable to add an asname attribute because it > > * will simplify server client requests and is used explicitly > > * by some tools. Just as netnames for IP addresses have proved > > * useful and are often listed independently, we think that it > > * would be useful to have an attribute which is explicitly > > * for AS names. For example, the "AStrace" tool explicitly uses > > * this information and AS names have proven useful in much of our PRDB work. > > * > > I think this is a good thing to do as well. I am going to add this > > into the text later today. I will leave in description as well. One > > problem we have in terms of backward compatability is I will have to > > make AS name optional. Is this going to cause you a lot of heart burn > > otherwise we have yet another tranisition to do. > > I support this as well. > Tony, not heartburn, but it would be nice to make it mandatory and grandfather in the data that exists without it. And any tools that need an asname can default to just returning the asnumber instead. > > * 4) the proposal for a change time attribute > > * > > Firstly, as said before this is totally outside the context of > > RIPE-81++. I know what the suggestion is and has already been put by > > Laurent to the DB wg. As far as I remember it was deemed "not worth > > doing" by the chair. Please send a message about this again if you > > want to see any progress on this I would say. > > I also support this, and I will discuss it with Wilfried. > OK, we'll lobby the DB working group. See you all in Lisbon. --Elise -------- Logged at Wed Sep 7 00:11:51 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed Sep 7 00:11:48 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 07 Sep 1994 00:11:48 +0200 Subject: Draft of RIPE81++ In-Reply-To: Your message of Tue, 06 Sep 1994 16:52:44 EDT. <9409062052.AA00991@pepper.merit.edu> Message-ID: <9409062211.AA07926@rijp.ripe.net> * > > I dont agree on the inconsistencies. The type of people who will use * > > this attribute will know what their peers AS routers are. Lets face it * > > who runs there BGP peering without configuring the remote peer address? * * Whereas someone will always configure their peer router, we're not * convinced that folks will show the same attention to updating the * routing registry. Hold on, what is the point of a routing registry if you are not convinced people will update the information? If one cannot convince people to keep the routing registry up to date (ie if you do not give them an incentive to keep it up to date) the routing registry is useless. Partly correct information is worse than no information at all. If you think this is true for the peer router, isn't this true for any information people put in? The idea is that people work from the routing registry to a configuration and not vice versa. This is the only real incentive you can give people. But, let's not start a discussion on this, let's concentrate on the things that need a decision. I just think that arguing that people will not update the information is the wrong reason to have something mandatory or optional. * See you all in Lisbon. * --Elise You should probably send in a registration form.... -Marten -------- Logged at Wed Sep 7 01:02:48 MET DST 1994 --------- From Tony.Bates at ripe.net Wed Sep 7 01:02:45 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 07 Sep 1994 01:02:45 +0200 Subject: Draft of RIPE81++ In-Reply-To: Your message of Tue, 06 Sep 1994 16:52:44 EDT. <9409062052.AA00991@pepper.merit.edu> Message-ID: <9409062302.AA19527@mature.ripe.net> epg at merit.edu writes: * Jean-Michel and Tony, * Thanks for your comments. Let me preface my following responses with * a probably contentious statement (though I'm not looking for an * argument nor trying to start a fight) - we probably wouldn't be having * this debate if we had just modified as-in and as-out to optionally * include multi-exit discriminators. Then there would be no need for * interas-in and interas-out and there would be no need to translate * from interas-in/out to as-in/out. But I acknowledge that you all do * not want to modify as-in/out and therefore if we are to support * multi-exit discriminators, we need to have a new attribute. * Well..perhaps you have a point here...not sure though.. as we have modified it (it accepts netlists now). When we looked at it the only time MEDs were used were in the interas scenarios though right ?. * Just wanted to say that because as I responded to all this, it * seemed to me that we were trying to refine a kludge instead of focusing * on what we had started out to describe. Probably just grumpy 'cause * it's a nice day and I'm stuck inside. Now you are right about refining a kludge (IMHO somewhere we turned the whole thing into a kludge). However, I think the focus is still there of what (at least in my mind) interas is tying to define and it is what is depicted in the example. How to document more than one inter-AS conection between two ASes. * * So now for the responses to your responses.... * * Okay, I also am going to try to chop some of the text as already some of this is confused which what is mandatory and what is isn't. * * Guess, our thoughts on this are colored by working with folks like * BARRNET which have always had at least two gateways that peer with * our one gateway. BARRNET has then preferred to accept one set of * nets at one router and the rest of the nets at another router. * But how does this not fit into all stated. Barrnet clearly has a general policy (as-in/out) between Barrnet and AS690 (the union the two sets of routes) and clearly has a policy describable by the interas attributes ? * > > I dont agree on the inconsistencies. The type of people who will use * > > this attribute will know what their peers AS routers are. Lets face it * > > who runs there BGP peering without configuring the remote peer address? * > > * * Whereas someone will always configure their peer router, we're not * convinced that folks will show the same attention to updating the * routing registry. * Well then we are dead in the water then. How do we use tools without both ends ? - How do people understand the policy with ESP of the topology ? Even worse - if we assume people dont register except their info. why both at all ? * > > * Is there a way that we can leave the gateway statements as optional * * > > * and clarify the ambiguity business? For instance, there are several * * > > * ways to clarify this ambiguity. For instance we could simply decla * re that * > > * if there is one gateway, it is the local one. There are also easy * > > * syntax change options, such as allowing the token "-" to stand for * > > * one or both of the gateways to eliminate ambiguity. * > > * * > > Sure but this is not mandatory for solving the ambiguity. * > > * * Whoops, maybe I had a wrong assumption here. It seemed to me that * the local and remote gateway characteristics of the interas-in/out * attribute had been changed to mandatory (whereas they used to be * optional) because with the selected syntax listing one gateway * only would be ambiguous. Listing no gateways or two gateways is * unambiguous; it's only if you are permitted to list only one gateway * that there is no way to distinguish whether it is a local gateway or * a remote gateway. Have I made the incorrect assumption? * Nope - you are not under a mis-conception. They are both mandatory for reasons above. They can be changed if people agree and I can just be on my own on this one (no problem with that). But, let me re-iterate, they are not mandatory to solve the ambiguity problem or to force our ordering. They are mandatory so the provider documenting policy knows both end of the link. He has to know this. How many people have a passive BGP connection that does not care who connects to them ? * > Elise, I agree with you, there's no need to register information * > you don't need, it's more difficult to manage, but as Tony points * > out, why would anybody need this detailed information unless you * > really want to configure a box with it, in which case you *need* * > the local and remote addresses. Well, I don't know the answer, * > but you probably have such a case, otherwhise you would not ask * > for it :-) What I would propose is to: * > Wait though by proposing this we have them optional - Question is can you give a case ? and even if it exists are they changing so often and will be maintained by providers who wont update (hard to answer but important to issue). * > 1- Keep the ordering as it is in Ripe-81++ (to be close to the * > as-in syntax), * > * * OK * * > 2- Accept the Local and remote router info to be optional * > * * OK * * > 3- Solve the parsing issue by adding what Jessica proposed (L:... R:...) * > * * OK * My last try on this. It is obvious to solve ambiguity - there are a million different ways - I am not making them mandatory for this reason. The question is how we will use them if they are optional and should we make the assumptionthat users of the registry only care about there own data. Also, please tell me how this all fits (in terms of reasoning for optional is we have only a remote gateway registered - this just turns the whole argument upside down). * > Well, I'm not sure I do agree with what I write, but if I can get a * > consensus ... * > Me either (referring to Jimi suggested resolution) and I would like to see if we do need to go to consensus on this that this is decided at the RIPE meeting. * Jimis text cut. Firstly, as-in is not mandatory - lets be clear on this. However.... * My assumption is that since neither as-in/out nor interas-in/out are * mandatory attributes within the aut-num object, it is unnecessary * to mandate a corresponding as-in/out attribute if there is an * interas-in/out attribute specified. The policy expressed in the * aut-num object should be the union of the as-in/out and interas-in/out * statements. * This is the one tricky one. I say yes it should become mandatory in the presence of a corresponding interas attribute so that the global info is clear. This is purely a clarity argument. If I understand the original argument for this was against duplicity of info. This I (always I - just my own view ;-)) beleive is very little extra info and far outwighed by some making use of the global info. Again as soon as I am once removed from the AS the local info is of zero consequnce but the global info is. * I think that we (both Merit and RIPE) have artifically added this * complexity because we all compromised on the way we added the multi- * discriminator information by creating a new attribute. Since we * have done this, we should try to avoid mandating a situation which * will knowingly misrepresent registered information. * It will not misrepresent but just have some levels of granularity. I believe on a personal view we compromised the registry the day we added the extra complexity (hows that for restructuring above ;-)) but I guess thats another story. * > > * * Jean-Michel, as-in/out has never been mandatory - at least from my * reading of the documents. So folks could previoulsy register an * aut-num without registering any policy. If we want to mandate that * folks have to register policy in aut-num; then that is a different Right - lets drop this (is as-in mandatory confusion) before we start. * reason to make as-in/out mandatory. But in that case mandating either * as-in/out or interas-in/out would suffice to meet the requirement. * * Since as-in/out has never been mandatory, I do not understand why * it should be mandatory if someone chooses to register interas-in/out. * See above for why I like this. * * > Personnaly, I don't think that the majority of the policies will * > use the interasin and I would prefer to keep the dupplication of * > information by keeping as-in and interasin (with as-in mandatory, * > and interasin optional), providing we can find a solution to * > preference issue in as-in... * > * * Repeat, of my previous comment - as-in has never been mandatory. * Agreed ;-). confusion confusion. * > > * 3) the proposal for an asname attribute * > > make AS name optional. Is this going to cause you a lot of heart burn * > > otherwise we have yet another tranisition to do. * > * > I support this as well. * > * * Tony, not heartburn, but it would be nice to make it mandatory * and grandfather in the data that exists without it. And any tools * that need an asname can default to just returning the asnumber * instead. But... this constitutes a change of data and hence a transition. We would make it optional for a period of time and then up it to madatory. This way not everyone has their entry bounced to start with and we can let then come in. We have three transitions to do for the RIPE routing registry and to have to change all AS objects is gonna be too much I fear. This also fits into your tool algorithm above. * * > > * 4) the proposal for a change time attribute * * OK, we'll lobby the DB working group. Fine. * --T -------- Logged at Tue Sep 20 15:57:02 MET DST 1994 --------- From lpj at merit.edu Tue Sep 20 15:56:58 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Tue, 20 Sep 1994 09:56:58 -0400 (EDT) Subject: Implementation of RIPE-181++ Message-ID: <199409201356.JAA21795@merit.edu> Just a question about the policy syntax and its implementation: o AS1 peers with AS2 at nap1, nap2, nap3 o AS1 accept from AS2 the networks in AS100 at nap1, nap2, nap3 o AS1 accept from AS2 the network {10/8} at nap3 *only* - How do you express this policy with the RIPE-81++ syntax (as-in/ interas-in stuff...) - What's the algorithm used to generate the filter list (list of nets accepted) of AS1 at nap1, nap2, nap3 Laurent PS: A beer for the first one who gives me a good answer :) PS/2: I do not know the solution -------- Logged at Tue Sep 20 16:12:55 MET DST 1994 --------- From Marten.Terpstra at ripe.net Tue Sep 20 16:12:40 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 20 Sep 1994 16:12:40 +0200 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Tue, 20 Sep 1994 09:56:58 EDT. <199409201356.JAA21795@merit.edu> Message-ID: <9409201412.AA23621@rijp.ripe.net> Laurent Joncheray writes * Just a question about the policy syntax and its implementation: * * o AS1 peers with AS2 at nap1, nap2, nap3 * o AS1 accept from AS2 the networks in AS100 at nap1, nap2, nap3 * o AS1 accept from AS2 the network {10/8} at nap3 *only* * * - How do you express this policy with the RIPE-81++ syntax (as-in/ * interas-in stuff...) * - What's the algorithm used to generate the filter list (list of nets * accepted) of AS1 at nap1, nap2, nap3 This can be done. However there are a few things which are not clear form the description of your policy: - is 10/8 inside AS100? - does AS1 accept only 10/8 at nap3 or also AS100 in addition to 10/8? Now, let's assume 10/8 is in AS100 and at nap3 it accepts the whole of AS100, including 10/8: aut-num: AS1 as-in: AS2 100 AS100 interas-in: AS2 as1nap1 as2nap1 AS100 AND NOT {10.0.0.0/8} interas-in: AS2 as1nap2 as2nap2 AS100 AND NOT {10.0.0.0/8} interas-in: AS2 as1nap3 as2nap3 AS100 What's difficult about this one? If 10/8 is not in AS100 or at nap3 there is something else going on, please explain, and I'll try and write it up. The simple case is where at nap3 AS1 does not accept the whole of AS100, but only that one network in AS100. Then the last line would be: interas-in: AS2 as1nap3 as2nap3 AS100 AND {10.0.0.0/8} I am afraid I missed the difficulty here.... -MT -------- Logged at Tue Sep 20 16:20:04 MET DST 1994 --------- From lpj at merit.edu Tue Sep 20 16:19:54 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Tue, 20 Sep 1994 10:19:54 -0400 (EDT) Subject: Implementation of RIPE-181++ Message-ID: <199409201419.KAA23513@merit.edu> (a revised version) Just a question about the policy syntax and its implementation: o AS1 peers with AS2 at nap1, nap2, nap3 o AS1 accept from AS2 the networks in AS100 at nap1, nap2, nap3 o AS1 accept from AS2 the network {10/8} at nap3 *only* o 10/8 is not in AS100 - How do you express this policy with the RIPE-81++ syntax (as-in/ interas-in stuff...) - What's the algorithm used to generate the filter list (list of nets accepted) of AS1 at nap1, nap2, nap3 Laurent PS: A beer for the first one who gives me a good answer :) PS/2: I do not know the solution -- Laurent -------- Logged at Tue Sep 20 16:23:12 MET DST 1994 --------- From ala at merit.edu Tue Sep 20 16:23:07 1994 From: ala at merit.edu (Andrew Adams) Date: Tue, 20 Sep 1994 10:23:07 -0400 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of "Tue, 20 Sep 1994 10:19:54 EDT." <199409201419.KAA23513@merit.edu> Message-ID: <199409201423.KAA24012@merit.edu> Couldn't you express this with the interas-in attribute? Say that the following addresses<->router mappsings are valid. NAP ---- NAP1 AS1 192.141.10.1 NAP1 AS2 192.141.10.2 NAP2 AS1 192.142.10.1 NAP2 AS2 192.142.10.2 NAP3 AS1 192.143.10.1 NAP3 AS2 192.143.10.2 Then wouldn't the policy be... aut-num: AS1 interas-in: from AS2 192.141.10.1 192.141.10.2 accept AS2 interas-in: from AS2 192.142.10.1 192.142.10.2 accept AS2 interas-in: from AS2 192.143.10.1 192.143.10.2 accept AS2 AND {10/8} -Andy > Just a question about the policy syntax and its implementation: > >o AS1 peers with AS2 at nap1, nap2, nap3 >o AS1 accept from AS2 the networks in AS100 at nap1, nap2, nap3 >o AS1 accept from AS2 the network {10/8} at nap3 *only* > > - How do you express this policy with the RIPE-81++ syntax (as-in/ > interas-in stuff...) > - What's the algorithm used to generate the filter list (list of nets > accepted) of AS1 at nap1, nap2, nap3 > > Laurent > >PS: A beer for the first one who gives me a good answer :) >PS/2: I do not know the solution -Andy > (a revised version) > Just a question about the policy syntax and its implementation: > >o AS1 peers with AS2 at nap1, nap2, nap3 >o AS1 accept from AS2 the networks in AS100 at nap1, nap2, nap3 >o AS1 accept from AS2 the network {10/8} at nap3 *only* >o 10/8 is not in AS100 > > - How do you express this policy with the RIPE-81++ syntax (as-in/ > interas-in stuff...) > - What's the algorithm used to generate the filter list (list of nets > accepted) of AS1 at nap1, nap2, nap3 > > Laurent > >PS: A beer for the first one who gives me a good answer :) >PS/2: I do not know the solution > >-- >Laurent -------- Logged at Tue Sep 20 16:26:40 MET DST 1994 --------- From Marten.Terpstra at ripe.net Tue Sep 20 16:26:29 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 20 Sep 1994 16:26:29 +0200 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Tue, 20 Sep 1994 10:23:07 EDT. <199409201423.KAA24012@merit.edu> Message-ID: <9409201426.AA23676@rijp.ripe.net> * Couldn't you express this with the interas-in attribute? Yes. * Then wouldn't the policy be... * * aut-num: AS1 * interas-in: from AS2 192.141.10.1 192.141.10.2 accept AS2 * interas-in: from AS2 192.142.10.1 192.142.10.2 accept AS2 * interas-in: from AS2 192.143.10.1 192.143.10.2 accept AS2 AND {10/8 * } Careful with the AND and OR here. AND is a boolean AND, OR a boolen OR. Ie, your last interas-in line will only accept 10/8 if it is in AS2 (the example said AS100 but that does not matter). If you want AS2 and 10/8 and you do not care what AS 10/8 is in, this should be an OR (see my previous mail). -Marten PS Does this mean lpj owes me a beer yet ;-? -------- Logged at Tue Sep 20 16:38:33 MET DST 1994 --------- From Marten.Terpstra at ripe.net Tue Sep 20 16:38:17 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 20 Sep 1994 16:38:17 +0200 Subject: Implementation of RIPE-181++ (fwd) In-Reply-To: Your message of Tue, 20 Sep 1994 10:28:13 EDT. <199409201428.KAA24358@merit.edu> Message-ID: <9409201438.AA23698@rijp.ripe.net> [Laurent] * > Every net listed in interas-in should be in as-in also. Your nacr will * > be rejected. * > what about the algorithm? * > * > Laurent [Andy] * > > aut-num: AS1 * > > interas-in: from AS2 192.141.10.1 192.141.10.2 accept AS2 * > > interas-in: from AS2 192.142.10.1 192.142.10.2 accept AS2 * > > interas-in: from AS2 192.143.10.1 192.143.10.2 accept AS2 AND { * 10/8} At this point I am totally lost. My solution was: aut-num: AS1 as-in: AS2 100 AS100 OR {10.0.0.0/8} interas-in: AS2 as1nap1 as2nap1 AS100 interas-in: AS2 as1nap2 as2nap2 AS100 interas-in: AS2 as1nap3 as2nap3 AS100 OR {10.0.0.0/8} All nets listed in interas-in are listed in as-in. The as-in is simply a rewrite of: (AS100) OR (AS100) OR (AS100 OR {10.0.0.0/8}) (which is all interas-in expressions OR'ed together, the global policy is the union of all local policies....) The algorithm is easy (for any of the above policy expressions). For every net/route found in the database, check whether the match the boolean policy expression. So, in the as-in or nap3 interas-in case they would have an origin of AS100 or they would have to be route 10.0.0.0/8. This is no different than any policy expression. I still do not see the difficulty..... -Marten -------- Logged at Tue Sep 20 16:46:10 MET DST 1994 --------- From GeertJan.deGroot at ripe.net Tue Sep 20 16:46:02 1994 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Tue, 20 Sep 1994 16:46:02 +0200 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of "Tue, 20 Sep 1994 16:26:29 MDT." <9409201426.AA23676@rijp.ripe.net> Message-ID: <9409201446.AA23875@belegen.ripe.net> On Tue, 20 Sep 1994 16:26:29 +0200 Marten Terpstra wrote: >Subject: Re: Implementation of RIPE-181++ ^^^^^ I didn't know we were going this fast ;-) Geert Jan -------- Logged at Tue Sep 20 16:56:37 MET DST 1994 --------- From Marten.Terpstra at ripe.net Tue Sep 20 16:56:27 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 20 Sep 1994 16:56:27 +0200 Subject: Implementation of RIPE-181++ (fwd) In-Reply-To: Your message of Tue, 20 Sep 1994 10:43:16 EDT. <199409201443.KAA25785@merit.edu> Message-ID: <9409201456.AA23755@rijp.ripe.net> I have CC'ed the list again... Laurent Joncheray writes * > The algorithm is easy (for any of the above policy expressions). For * > every net/route found in the database, check whether the match the * > boolean policy expression. So, in the as-in or nap3 interas-in case * > they would have an origin of AS100 or they would have to be route * > 10.0.0.0/8. This is no different than any policy expression. I still * > do not see the difficulty..... * * There is no diffilculty. I just want to be sure of the correct syntax. * Could you detail the algorithm? What to do if there are as-in and interas-in * , * only as-in, only interas-in (error), nothing? which one to choose first? * Laurent OK Here goes. ripe-81++ says pp 27-28 in ascii version: "Descriptions of interas policies do not replace the global pol- icy described in as-in, as-out and other policy attributes which should be specified too. If the global policy mentions more routes than the local policy then local preferences for these routes are assumed to be equal for all links. Any route specified in interas-in/out and not specified in as-in/out is assumed not accepted/announced between the ASes concerned. Diag- nostic tools should flag this inconsistency as an error. It should be noted that if an interas-in or interas-out policy is specified then it is mandatory to specify the corresponding global policy in the as-in or as-out line. Please note there is no relevance in the cost associated with as-in and the preferences used in interas-in." I think this can be done by calculating the intersection between the various expressions. My solution can (with the above in mind) even be written as: aut-num: AS1 as-in: AS2 100 AS100 OR {10.0.0.0/8} interas-in: AS2 as1nap3 as2nap3 {10.0.0.0/8} This means that you only have to list the exceptions in interas-in. The above is of course only true if they all have the same metric. A different metric means an exception. * PS: You're getting close to the beer.... I want that beer..... -Marten -------- Logged at Tue Sep 20 17:08:33 MET DST 1994 --------- From lpj at merit.edu Tue Sep 20 17:08:27 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Tue, 20 Sep 1994 11:08:27 -0400 (EDT) Subject: Implementation of RIPE-181++ (fwd) In-Reply-To: <9409201456.AA23755@rijp.ripe.net> from "Marten Terpstra" at Sep 20, 94 04:56:27 pm Message-ID: <199409201508.LAA27782@merit.edu> > I think this can be done by calculating the intersection between the > various expressions. > > My solution can (with the above in mind) even be written as: > > aut-num: AS1 > as-in: AS2 100 AS100 OR {10.0.0.0/8} > interas-in: AS2 as1nap3 as2nap3 {10.0.0.0/8} I like that one. Shorter than your previous solution. What about the algorithm? what i like to see is something like: How to generate the net list for AS1 at napX: If there is a interas-in statment for AS1-AS2 link at napX then list all nets in the policy expression (the stuff after the 'aacept' keyword) If there is no interas-in statment but an as-in statment for AS1-AS2 policy then list all nets in the policy expression. If there is no interas-in statment and no as-in statment then ERROR! If there is an interas-in statment and no as-in statment then ERROR! (syntax error) etc... Remark: this algorithm does not work with the solution you proposed. -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Tue Sep 20 17:50:34 MET DST 1994 --------- From Marten.Terpstra at ripe.net Tue Sep 20 17:50:30 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 20 Sep 1994 17:50:30 +0200 Subject: RIPE Database playground Message-ID: <9409201550.AA23893@rijp.ripe.net> Folks, As requested at the last RIPE meeting, I have setup a test database for you all to use and get some feeling of how all this works. Some details: - the "inetnum" and "route" objects (new format, ie after the split) will be regenerated every night, and will overwrite any changes/additions you may have sent in. - all other objects remain in the test database - the address to send test data to is: test-dbm at ripe.net - there is a whois server running on this database on machine "bwhois.ripe.net", normal whois port 43. - most of the functionaility of ripe-81++, authorisation, inet-rtr and all other docs presented at the RIPE meeting has been implemented. - there are a few things that still need implementation, try: "whois -h bwhois.ripe.net help" for help and open issues. - Bugs/Questions please to me directly (or ripe-dbm), or to the list if you think it is important enough. - most unix type clients will understand extra options (see the help for a complete list) as: % whois -h bwhois.ripe.net -- -L key or % whois -h bwhois.ripe.net "-L key" I will send a similar mail to the local-ir list and all guardians later this week or early next week, you are the first ones to have a go at it. Go! -Marten -------- Logged at Tue Sep 20 19:57:45 MET DST 1994 --------- From cengiz at ISI.EDU Tue Sep 20 19:57:31 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 20 Sep 1994 10:57:31 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <199409201419.KAA23513@merit.edu> References: <199409201419.KAA23513@merit.edu> Message-ID: <199409201757.AA00593@chl.isi.edu> Laurent Joncheray (lpj at merit.edu) on September 20: > (a revised version) > Just a question about the policy syntax and its implementation: > > o AS1 peers with AS2 at nap1, nap2, nap3 > o AS1 accept from AS2 the networks in AS100 at nap1, nap2, nap3 > o AS1 accept from AS2 the network {10/8} at nap3 *only* > o 10/8 is not in AS100 > > - How do you express this policy with the RIPE-81++ syntax (as-in/ > interas-in stuff...) > - What's the algorithm used to generate the filter list (list of nets > accepted) of AS1 at nap1, nap2, nap3 I think this question and the one I asked a week back are both due to the ambiguity on the relation between as-in and interas-in. I think the relation between as-in and interas-in needs to be made clear and explicit. >From the perspective of someone who read ripe181 Sep 16 version, all solutions proposed do not solve Laurant's problem. I.e. solutions are not consistent with ripe181 document. Marten Terpstra (Marten.Terpstra at ripe.net) on September 20: > aut-num: AS1 > as-in: AS2 100 AS100 OR {10.0.0.0/8} > interas-in: AS2 as1nap1 as2nap1 AS100 > interas-in: AS2 as1nap2 as2nap2 AS100 > interas-in: AS2 as1nap3 as2nap3 AS100 OR {10.0.0.0/8} ripe-81++ says pp 27-28 in ascii version: If the global policy mentions more routes than the local policy then local preferences for these routes are assumed to be equal for all links. My interpretation is as follows: as-in: AS2 100 AS100 OR {10.0.0.0/8} mentions more routes than interas-in: AS2 as1nap1 as2nap1 AS100. I.e. it mentions {10.0.0.0/8} extra. Hence, "local preferences for {10.0.0.0/8} are assumed to be equal for all links". All links include "as1nap1 as2nap1" Hence, AS1 accepts {10.0.0.0/8} on nap1 as well. Marten Terpstra (Marten.Terpstra at ripe.net) on September 20: > aut-num: AS1 > as-in: AS2 100 AS100 OR {10.0.0.0/8} > interas-in: AS2 as1nap3 as2nap3 {10.0.0.0/8} This will make AS1 accept {10.0.0.0/8} on nap1 and nap2 as well. Since policies on those naps will be the one in as-in. Also interesting to see that this solution contradicts the previous one: Previous solution is correct if local policies did not copy extra routes from global policies. This solution is correct (only for nap3) if it did. Perhaps, with the current ripe181 document, there is no correct solution. If this is the case, Laurant owes me a beer. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Tue Sep 20 21:43:14 MET DST 1994 --------- From Marten.Terpstra at ripe.net Tue Sep 20 21:42:29 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 20 Sep 1994 21:42:29 +0200 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Tue, 20 Sep 1994 10:57:31 PDT. <199409201757.AA00593@chl.isi.edu> Message-ID: <9409201942.AA17224@ncc.ripe.net> * I think this question and the one I asked a week back are both due to * the ambiguity on the relation between as-in and interas-in. I think * the relation between as-in and interas-in needs to be made clear and * explicit. Seeing the different interpretations of the text, we indeed need to make this clear. * >From the perspective of someone who read ripe181 Sep 16 version, all * solutions proposed do not solve Laurant's problem. I.e. solutions are * not consistent with ripe181 document. * * Marten Terpstra (Marten.Terpstra at ripe.net) on September 20: * > aut-num: AS1 > as-in: AS2 100 AS100 OR {10.0.0.0/8} * > interas-in: AS2 as1nap1 as2nap1 AS100 * > interas-in: AS2 as1nap2 as2nap2 AS100 * > interas-in: AS2 as1nap3 as2nap3 AS100 OR {10.0.0.0/8} * * ripe-81++ says pp 27-28 in ascii version: * * If the global policy mentions more routes than the local policy * then local preferences for these routes are assumed to be equal for * all links. * * My interpretation is as follows: * as-in: AS2 100 AS100 OR {10.0.0.0/8} * mentions more routes than * interas-in: AS2 as1nap1 as2nap1 AS100. * I.e. it mentions {10.0.0.0/8} extra. * Hence, * "local preferences for {10.0.0.0/8} are assumed to be equal for all * links". * * All links include "as1nap1 as2nap1" Hence, AS1 accepts {10.0.0.0/8} on * nap1 as well. OK, to say what we actually mean, the paragraph in ripe-181 should say: "If the global policy mentions more routes than the *combined local policies* then local preferences for these routes are assumed to be equal for all links." This is what I understood this means. * Marten Terpstra (Marten.Terpstra at ripe.net) on September 20: * > aut-num: AS1 * > as-in: AS2 100 AS100 OR {10.0.0.0/8} * > interas-in: AS2 as1nap3 as2nap3 {10.0.0.0/8} * * This will make AS1 accept {10.0.0.0/8} on nap1 and nap2 as well. * Since policies on those naps will be the one in as-in. Yes and no, interpretation again. If you take my (modified) paragraph of above you can also say that *only* the surplus routes mentioned in as-in will be assumed equal for all links. Ie, only AS100 (which is not explicitly used in any interas-in rule) is assumed to be accepted equally on all links. There's an exception trule for 10/8 so that one should never be accepted on the other interas policies. Then again, if the other two interas rules are not there, how can you even generate a config for these two... * Perhaps, with the current ripe181 document, there is no correct * solution. If this is the case, Laurant owes me a beer. There is a solution, the problem we all have is the different interpretations of the as-in and interas-in combination. If you all agree with what I said above, we should try and rewrite that paragraph to more clearly explain what the interaction is. If we can find a common interpretation, I am sure an algorithm can be made. -Marten -------- Logged at Tue Sep 20 23:04:04 MET DST 1994 --------- From cengiz at ISI.EDU Tue Sep 20 23:03:21 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 20 Sep 1994 14:03:21 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <9409201942.AA17224@ncc.ripe.net> References: <199409201757.AA00593@chl.isi.edu> <9409201942.AA17224@ncc.ripe.net> Message-ID: <199409202103.AA00625@chl.isi.edu> Marten, It is interesting to see your interpretation. Marten Terpstra (Marten.Terpstra at ripe.net) on September 20: > "If the global policy mentions more routes than the *combined local > policies* then local preferences for these routes are assumed to be > equal for all links." With this I am no longer confused. I see that both of your solutions are correct with this interpretation: Marten Terpstra (Marten.Terpstra at ripe.net) on September 20: > aut-num: AS1 > as-in: AS2 100 AS100 OR {10.0.0.0/8} > interas-in: AS2 as1nap1 as2nap1 AS100 > interas-in: AS2 as1nap2 as2nap2 AS100 > interas-in: AS2 as1nap3 as2nap3 AS100 OR {10.0.0.0/8} Marten Terpstra (Marten.Terpstra at ripe.net) on September 20: > aut-num: AS1 > as-in: AS2 100 AS100 OR {10.0.0.0/8} > interas-in: AS2 as1nap3 as2nap3 {10.0.0.0/8} However, this interpretation is not natural and is not easy to understand for a more general reader. Especially your second solution: Marten Terpstra (Marten.Terpstra at ripe.net) on September 20: > aut-num: AS1 > as-in: AS2 100 AS100 OR {10.0.0.0/8} > interas-in: AS2 as1nap3 as2nap3 {10.0.0.0/8} Natural policy for nap1 and nap2 is the one in as-in: accept AS100 OR {10.0.0.0/8}. But in fact, the policy for nap1 and nap2 is accept AS100 since {10.0.0.0/8} is mentioned in a local policy. A non-careful/ignorant administrator will think the first way. If the administrators of AS1 were even less careful and typed: aut-num: AS1 as-in: AS2 100 AS100 OR {10.0.0.0/8} interas-in: AS2 as1nap3 as2nap3 AS100 OR {10.0.0.0/8} the policy for nap1 and nap2 is accept NOT ANY since both AS100 {10.0.0.0/8} are mentioned in a local policy. This is even scarier, if {10.0.0.0/8} was in AS100 and AS1 did not accept {10.0.0.0/8} on nap3: aut-num: AS1 as-in: AS2 100 AS100 interas-in: AS2 as1nap3 as2nap3 AS100 AND NOT {10.0.0.0/8} the policy for nap1 and nap2 is accept {10.0.0.0/8} To sum-up with the new text (and with better explained "combined local policies"), I think there is no more ambiguity. However, it is a difficult and unnatural solution. How about the following solution: as-in policies are used in all links for which no interas-in policy is explicitly specified (like a default interas-in policy). If for a link an interas-in policy is specified, it is used and as-in policies are ignored. with this the correct solution to Laurant's problem is: aut-num: AS1 as-in: AS2 100 AS100 interas-in: AS2 as1nap3 as2nap3 AS100 OR {10.0.0.0/8} If a tool needs to know the global combined policy of an AS1, it takes the union of all as-in and interas-in policies. AS100 OR (AS100 OR {10.0.0.0/8}) = AS100 OR {10.0.0.0/8}. To me this is more natural. Cengiz P.S. Do we get to split the beer? -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Sep 22 16:21:31 MET DST 1994 --------- From lpj at merit.edu Thu Sep 22 16:21:23 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 22 Sep 1994 10:21:23 -0400 (EDT) Subject: Implementation of RIPE-181++ Message-ID: <199409221421.KAA21810@merit.edu> Hey dudes, any winner so far? I reaaly like to see the algorithm in order to be able to implement something. So far i got half of the answer from Marten and a complete (but wrong) answer from Cengiz. Enjoy... Laurent > (a revised version) > Just a question about the policy syntax and its implementation: > > o AS1 peers with AS2 at nap1, nap2, nap3 > o AS1 accept from AS2 the networks in AS100 at nap1, nap2, nap3 > o AS1 accept from AS2 the network {10/8} at nap3 *only* > o 10/8 is not in AS100 > > - How do you express this policy with the RIPE-81++ syntax (as-in/ > interas-in stuff...) > - What's the algorithm used to generate the filter list (list of nets > accepted) of AS1 at nap1, nap2, nap3 > > Laurent > > PS: A beer for the first one who gives me a good answer :) > PS/2: I do not know the solution > > -- > Laurent > -- Laurent -------- Logged at Thu Sep 22 17:07:00 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu Sep 22 17:06:53 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 22 Sep 1994 17:06:53 +0200 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Thu, 22 Sep 1994 10:21:23 EDT. <199409221421.KAA21810@merit.edu> Message-ID: <9409221506.AA27883@rijp.ripe.net> Laurent Joncheray writes * Hey dudes, any winner so far? I reaaly like to see the algorithm * in order to be able to implement something. So far i got half of the answer * from Marten and a complete (but wrong) answer from Cengiz. * Enjoy... * Laurent Daniel and Tony are both not in this week to see how we clarify the relation between as-in and interas-in... -Marten -------- Logged at Thu Sep 22 18:01:13 MET DST 1994 --------- From Tony.Bates at ripe.net Thu Sep 22 18:01:03 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Thu, 22 Sep 1994 18:01:03 +0200 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Thu, 22 Sep 1994 17:06:53 MDT. <9409221506.AA27883@rijp.ripe.net> Message-ID: <9409221601.AA00475@mature.ripe.net> Marten Terpstra writes: * * Laurent Joncheray writes * * Hey dudes, any winner so far? I reaaly like to see the algorithm * * in order to be able to implement something. So far i got half of the ans * wer * * from Marten and a complete (but wrong) answer from Cengiz. * * Enjoy... * * Laurent * Okay, I am jumping in a little. However, I will try to explain it as I tried to write it in the document. Basically, the as-in line is always the superset of the interas-in policies. Lets take each one in turn of possible problems. I have written in sort of simple terms as well. 1) You have policies in interas-in not described in as-in. They are ignored. To work it out....it is the difference of set of interas-ins minus the as-in and what is left is ignored. 2) You have more policy in as-in than described in interas-in. The polices not specifically defined in interas-in but mentioned in as-in are deemed equal across all interas-in peers/links. To work it is the difference of the as-in minus the set of interas-ins and what is left is shared across the links/peers. This implies adding to basic list generated for interas-in lines. 3) You have something like AS granularity in as-in and some network granularity in interas-in. i.e. as-in: ASX 100 AS2 interas-in: ASX a b blah {15.0.0.0/8} interas-in: ASX c d blah {10.0.0.0/8} You must always apply rule 1 above. First make sure 10.0.0.0/8 and 15.0.0.0/8 are in AS2, otherwise they are not accepted. If they are then make list such that 15 is best a-b anf 10 best c-d and the rest of AS2 is equal through both links. --Tony. -------- Logged at Thu Sep 22 19:04:12 MET DST 1994 --------- From cengiz at ISI.EDU Thu Sep 22 19:02:44 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 22 Sep 1994 10:02:44 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <9409221601.AA00475@mature.ripe.net> References: <9409221506.AA27883@rijp.ripe.net> <9409221601.AA00475@mature.ripe.net> Message-ID: <199409221702.AA02411@chl.isi.edu> Tony Bates (Tony.Bates at ripe.net) on September 22: > 3) You have something like AS granularity in as-in and some network > granularity in interas-in. i.e. > > as-in: ASX 100 AS2 > interas-in: ASX a b blah {15.0.0.0/8} > interas-in: ASX c d blah {10.0.0.0/8} > > You must always apply rule 1 above. First make sure 10.0.0.0/8 and > 15.0.0.0/8 are in AS2, otherwise they are not accepted. If they are > then make list such that 15 is best a-b anf 10 best c-d and the rest > of AS2 is equal through both links. Wanted to clarify two points: 1) {15.0.0.0/8} is not accepted at all on (c d). {10.0.0.0/8} is not accepted at all on (a b). (You used "15 is best a-b" which does not explicitly say it is not accepted on c-d). 2) If there was a third link (e, f) for which there is no interas-in line. The policies for that link is: networks in AS2 setminus {15.0.0.0/8} setminus {10.0.0.0/8} Just wanted to make sure. I think this complicated interaction of as-in and interas-in will be confused by a lot of people. Luckily only few and hopefully more knowledgable people will actually specify these. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Sep 22 19:12:48 MET DST 1994 --------- From cengiz at ISI.EDU Thu Sep 22 19:12:22 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 22 Sep 1994 10:12:22 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <199409221421.KAA21810@merit.edu> References: <199409221421.KAA21810@merit.edu> Message-ID: <199409221712.AA02414@chl.isi.edu> Laurent Joncheray (lpj at merit.edu) on September 22: > So far i got half of the answer from Marten and a complete (but > wrong) answer from Cengiz. Are you trying to avoid buying me a beer:-) Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Sep 22 19:24:25 MET DST 1994 --------- From Tony.Bates at ripe.net Thu Sep 22 19:24:15 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Thu, 22 Sep 1994 19:24:15 +0200 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Thu, 22 Sep 1994 10:02:44 PDT. <199409221702.AA02411@chl.isi.edu> Message-ID: <9409221724.AA00557@mature.ripe.net> cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * * Tony Bates (Tony.Bates at ripe.net) on September 22: * > 3) You have something like AS granularity in as-in and some network * > granularity in interas-in. i.e. * > * > as-in: ASX 100 AS2 * > interas-in: ASX a b blah {15.0.0.0/8} * > interas-in: ASX c d blah {10.0.0.0/8} * > * > You must always apply rule 1 above. First make sure 10.0.0.0/8 and * > 15.0.0.0/8 are in AS2, otherwise they are not accepted. If they are * > then make list such that 15 is best a-b anf 10 best c-d and the rest * > of AS2 is equal through both links. * * Wanted to clarify two points: * 1) * {15.0.0.0/8} is not accepted at all on (c d). * {10.0.0.0/8} is not accepted at all on (a b). * No - it is accepted but with pref as noted. Global policy means we cannot make this assumption. You can easily write it down more explicitly if you wanted the above effect. * (You used "15 is best a-b" which does not explicitly say it is not * accepted on c-d). * * 2) * If there was a third link (e, f) for which there is no interas-in * line. The policies for that link is: * networks in AS2 setminus {15.0.0.0/8} setminus {10.0.0.0/8} * Nope - would be all AS2 but with adjusted prefs for 10 and 15. * Just wanted to make sure. I think this complicated interaction of * as-in and interas-in will be confused by a lot of people. Luckily only * few and hopefully more knowledgable people will actually specify * these. * I concur a little on the cofusion but for those who will use it it will not be a big problem I would say. * Cengiz * * -- * Cengiz Alaettinoglu Information Sciences Institute * cengiz at isi.edu University of Southern California * --Tony. -------- Logged at Thu Sep 22 19:41:19 MET DST 1994 --------- From cengiz at ISI.EDU Thu Sep 22 19:40:44 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 22 Sep 1994 10:40:44 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <9409221601.AA00475@mature.ripe.net> References: <9409221506.AA27883@rijp.ripe.net> <9409221601.AA00475@mature.ripe.net> Message-ID: <199409221740.AA02429@chl.isi.edu> Tony Bates (Tony.Bates at ripe.net) on September 22: > 2) You have more policy in as-in than described in interas-in. > > The polices not specifically defined in interas-in but mentioned in > as-in are deemed equal across all interas-in peers/links. TO WORK IT > IS THE DIFFERENCE OF THE AS-IN MINUS THE SET OF INTERAS-INS AND WHAT IS > LEFT IS SHARED ACROSS THE LINKS/PEERS. This implies adding to basic > list generated for interas-in lines. Tony Bates (Tony.Bates at ripe.net) on September 22: > > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > * > * Tony Bates (Tony.Bates at ripe.net) on September 22: > * > 3) You have something like AS granularity in as-in and some network > * > granularity in interas-in. i.e. > * > > * > as-in: ASX 100 AS2 > * > interas-in: ASX a b blah {15.0.0.0/8} > * > interas-in: ASX c d blah {10.0.0.0/8} THE DIFFERENCE OF AS-IN MINUS THE SET OF INTERAS-INS AS2 minus ({15.0.0.0/8} or {10.0.0.0/8}) so both {15.0.0.0/8} and {10.0.0.0/8} are not shared. this is consistent with what Marten said the other day. Right Marten? Perhaps the above algorithm is wrong. > * Wanted to clarify two points: > * 1) > * {15.0.0.0/8} is not accepted at all on (c d). > * {10.0.0.0/8} is not accepted at all on (a b). > * > No - it is accepted but with pref as noted. Global policy means we > cannot make this assumption. You can easily write it down more > explicitly if you wanted the above effect. Please do so. Please also specify the following policy. AS1 accepts AS100,AS200 from AS2. On link (a,b), it only accepts AS100 (i.e. it does NOT accept AS200 on this link). On link (c,d), it only accepts AS200 (i.e. it does NOT accept AS100 on this link). This is the revisited barnet example of Elise. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Fri Sep 23 16:24:00 MET DST 1994 --------- From dsj at merit.edu Fri Sep 23 16:23:57 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 23 Sep 1994 10:23:57 -0400 Subject: Common communities across registries Message-ID: <199409231423.KAA14631@merit.edu> Marten, We probably will soon have need to make use of the "COMM_NSFNET" community. (Like next week). Is anything special required for registering a community on this side of the ocean, and having it recognized in Route objects on your side? (Has this been thought through yet?) --Dale -------- Logged at Mon Sep 26 03:28:23 MET 1994 --------- From epg at merit.edu Mon Sep 26 03:28:19 1994 From: epg at merit.edu (Elise Gerich) Date: Sun, 25 Sep 1994 22:28:19 -0400 Subject: Implementation of RIPE-181++ Message-ID: <199409260228.WAA14518@merit.edu> Hmmmmmmmmmm...seems like the text is a bit fuzzy, or at least open to interpretation. AS-in is the sum of the policies between any two ASes. Yes? Therefore, if any session (we are not really talking links) between two ASs does not equal the sum (as-in), all of the sessions (interas-in statements) should be explicitly defined to identify unabiguously the addends. So in Laurent's scenario, there are three sessions. The total policy for as1 is to accept from as2 the set of nets belonging to as100 and also to accept net {10/8}. The sessions between as1 and as2 at naps 1 and 2 are unequal to the sum (looking at each session independently). Therefore, It is necessary to explicitly describe all sessions between as1 and as2 for clarity. aut-num: as1 as-in: from as2 accept as100 OR {10.0.0.0/8} interas-in: from as2 L1 R1 accept as100 interas-in: from as2 L2 R2 accept as100 interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8} If someone registers this as: aut-num: as1 as-in: from as2 accept as100 OR {10.0.0.0/8} interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8} The policy would be assumed to be equal for all sessions - even though that is not explicitely stated. There is no way to determine the exception to the global (sum ofthe policies)policy. If someone registers this as: aut-num: as1 as-in: from as2 accept as100 OR {10.0.0.0/8} interas-in: from as2 L1 R1 accept as100 The policy for the other two sessions would be assumed to be equal to the policy stated in the as-in statement. The interas-in line that is explicitely stated is assumed to be the exception from the total sum of the policies. It should be unambiguous if the maintainers explicitly define all sessions. If the maintainers do not, I propose that we determine the undefined sessions in the way previously described. --Elise -------- Logged at Mon Sep 26 21:59:07 MET 1994 --------- From epg at merit.edu Mon Sep 26 21:59:01 1994 From: epg at merit.edu (Elise Gerich) Date: Mon, 26 Sep 1994 16:59:01 -0400 (EDT) Subject: Implementation of RIPE-181++ In-Reply-To: <199409260228.WAA14518@merit.edu> from "Elise Gerich" at Sep 25, 94 10:28:19 pm Message-ID: <199409262059.QAA13894@merit.edu> Oh well, Laurent has been beating me up because I did not include an algorithim. So based on the text expressed in my previous message, If you want to generate a net list for AS1 at nap3, then: If there is an an as-in statement for AS2 and there is an interas-in statement for the session between AS1 and AS2 at NAP 3 (i.e aut-num: as1 as-in: from as2 accept as100 OR {10.0.0.0/8} interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8}) then list all of the nets in interas-in expression after the keyword accept. If there is an an as-in statement for AS2 and there is no interas-in statement for the session between AS1 and AS2 at NAP3 (i.e. aut-num: as1 as-in: from as2 accept as100 OR {10.0.0.0/8} interas-in: from as2 L1 R1 accept as100) then list all of the nets in the as-in expression. Ifthere is not an as-in statement for AS2 and there is an interas-in statement for the session between AS1 and AS2 at NAP 3 (i.e. interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8}) then you have an error. --Elise > > Hmmmmmmmmmm...seems like the text is a bit fuzzy, or at least > open to interpretation. > > AS-in is the sum of the policies between any two ASes. Yes? > Therefore, if any session (we are not really talking links) > between two ASs does not equal the sum (as-in), all of the > sessions (interas-in statements) should be explicitly defined > to identify unabiguously the addends. > > So in Laurent's scenario, there are three sessions. The total > policy for as1 is to accept from as2 the set of nets belonging to > as100 and also to accept net {10/8}. The sessions between as1 and > as2 at naps 1 and 2 are unequal to the sum (looking at each session > independently). Therefore, It is necessary to explicitly describe all > sessions between as1 and as2 for clarity. > > aut-num: as1 > as-in: from as2 accept as100 OR {10.0.0.0/8} > interas-in: from as2 L1 R1 accept as100 > interas-in: from as2 L2 R2 accept as100 > interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8} > > If someone registers this as: > aut-num: as1 > as-in: from as2 accept as100 OR {10.0.0.0/8} > interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8} > The policy would be assumed to be equal for all sessions - even though > that is not explicitely stated. There is no way to determine the exception > to the global (sum ofthe policies)policy. > > If someone registers this as: > aut-num: as1 > as-in: from as2 accept as100 OR {10.0.0.0/8} > interas-in: from as2 L1 R1 accept as100 > The policy for the other two sessions would be assumed to be equal to the > policy stated in the as-in statement. The interas-in line that is explicitely > stated is assumed to be the exception from the total sum of the policies. > > It should be unambiguous if the maintainers explicitly define all sessions. > If the maintainers do not, I propose that we determine the undefined sessions > in the way previously described. > > --Elise > > -------- Logged at Tue Sep 27 10:38:17 MET 1994 --------- From Tony.Bates at ripe.net Tue Sep 27 10:36:50 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 27 Sep 1994 10:36:50 +0100 Subject: Common communities across registries In-Reply-To: Your message of Fri, 23 Sep 1994 10:23:57 EDT. <199409231423.KAA14631@merit.edu> Message-ID: <9409270936.AA13716@mature.ripe.net> Dale, I am pretty sure no one has got back about and I am just catching up on things. I guess the initial answer is no one has thought of this. However, I belive we can easily have a mechanism where can mirror your guardian objects (and vice versa). As I see it all we need is the object (and the maintainer objects as well) to make sure notification works. We can at least for now set something up to make this work. In the longer term this raises the incorporation of each others data. Something we have been over before but looks as though it needs more thought yet. --Tony. "Dale S. Johnson" writes: * Marten, * * We probably will soon have need to make use of the "COMM_NSFNET" * community. (Like next week). Is anything special required for * registering a community on this side of the ocean, and having it * recognized in Route objects on your side? (Has this been thought * through yet?) * * --Dale -------- Logged at Tue Sep 27 14:45:55 MET 1994 --------- From Tony.Bates at ripe.net Tue Sep 27 14:45:47 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 27 Sep 1994 14:45:47 +0100 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Mon, 26 Sep 1994 16:59:01 -0400. <199409262059.QAA13894@merit.edu> Message-ID: <9409271345.AA14526@mature.ripe.net> Elise Gerich writes: * Oh well, Laurent has been beating me up because I did not include * an algorithim. * * So based on the text expressed in my previous message, * * If you want to generate a net list for AS1 at nap3, then: * * If there is an an as-in statement for AS2 and there is an interas-in * statement for the session between AS1 and AS2 at NAP 3 * (i.e aut-num: as1 * as-in: from as2 accept as100 OR {10.0.0.0/8} * interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8}) * then list all of the nets in interas-in expression after the keyword accept * . * * If there is an an as-in statement for AS2 and there is no interas-in * statement for the session between AS1 and AS2 at NAP3 * (i.e. aut-num: as1 * as-in: from as2 accept as100 OR {10.0.0.0/8} * interas-in: from as2 L1 R1 accept as100) * then list all of the nets in the as-in expression. * * Ifthere is not an as-in statement for AS2 and there is * an interas-in statement for the session between AS1 * and AS2 at NAP 3 * (i.e. interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8}) * then you have an error. * --Elise This is correct and what I had said in words before I believe. The tricky bit and something I am going to try to add into RIPE-81++ is some text descibing the interaction a little better and making sure no ambiguity is there. I will try to do this later today and send that prtion of the text. --Tony. -------- Logged at Thu Sep 29 18:09:23 MET 1994 --------- From dsj at merit.edu Thu Sep 29 18:09:19 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 29 Sep 1994 13:09:19 -0400 Subject: How trustworthy are existing BGP AS Paths? Message-ID: <199409291709.NAA19443@merit.edu> RIPE Folks, In discussions about how to generate GateD configs for the Route Servers, we're coming up with choices between hard-configured net lists (like the PRDB), lists of ASs, AS-Path expressions, and "interpreted" AS lists (creating net lists by listing the Route objects which reference the given ASs). A couple of questions keep coming up in these discussions: How Trustworthy are the AS-Paths actually seen in current routing packets? How secure are they? (Can they be easily misconfigured?) Last winter we noticed that there were a fair number of BGP Paths that claimed by be complete, but which disagreed with each other about what the origin ASs for certain nets were. I believe Tony or Marten also said that they had investigated determining Origin ASs from BGP packets, and had found that the information currently being routed was frequently wrong. Is my memory correct on this? Does anyone know if there are still lots of misleading AS-paths being routed? Further vague memories: Did someone say that some ASs were intentionally fudging the AS-Paths, e.g., to make multiple ASs look like a single AS, for policy reasons? [Do I sound like Gordon Cook?] Also, AS-Path expressions are presumably not useful for expressing policy about EPG speakers. (?) All in all, if these things are true, do folks here have feelings about how advisable it is to implement policy in terms of AS-path expressions in 4Q94? Guesses about 3Q95? --Dale ---------- PS: After we get Dale's memory sorted out, it might be interesting to take this same question to BGPD. -------- Logged at Thu Sep 29 18:24:56 MET 1994 --------- From jyy at merit.edu Thu Sep 29 18:24:50 1994 From: jyy at merit.edu (Jessica Yu) Date: Thu, 29 Sep 1994 13:24:50 -0400 Subject: How trustworthy are existing BGP AS Paths? Message-ID: <199409291724.NAA20764@merit.edu> Dale, The reason for routes with different AS origins is not due to configuration errors but routing arrangement between ASs. When two ASs speak IGP between themselves but each BGPs with other ASs, such as the Michnet and UMnet situation, this would occur. Anyother problematic ASpath scnerarios? --jessica ------- Forwarded Message Return-Path: dsj at merit.edu Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA19465; Thu, 29 Sep 1994 13:09:30 -0400 Received: from merit.edu by ncc.ripe.net with SMTP id AA27687 (5.65a/NCC-2.8); Thu, 29 Sep 1994 18:09:21 +0100 Received: (dsj at localhost) by merit.edu (8.6.8.1/merit-1.0) id NAA19443 for rr-impl at ripe.net; Thu, 29 Sep 1994 13:09:19 -0400 Date: Thu, 29 Sep 1994 13:09:19 -0400 From: "Dale S. Johnson" Message-Id: <199409291709.NAA19443 at merit.edu> To: rr-impl at ripe.net Subject: How trustworthy are existing BGP AS Paths? RIPE Folks, In discussions about how to generate GateD configs for the Route Servers, we're coming up with choices between hard-configured net lists (like the PRDB), lists of ASs, AS-Path expressions, and "interpreted" AS lists (creating net lists by listing the Route objects which reference the given ASs). A couple of questions keep coming up in these discussions: How Trustworthy are the AS-Paths actually seen in current routing packets? How secure are they? (Can they be easily misconfigured?) Last winter we noticed that there were a fair number of BGP Paths that claimed by be complete, but which disagreed with each other about what the origin ASs for certain nets were. I believe Tony or Marten also said that they had investigated determining Origin ASs from BGP packets, and had found that the information currently being routed was frequently wrong. Is my memory correct on this? Does anyone know if there are still lots of misleading AS-paths being routed? Further vague memories: Did someone say that some ASs were intentionally fudging the AS-Paths, e.g., to make multiple ASs look like a single AS, for policy reasons? [Do I sound like Gordon Cook?] Also, AS-Path expressions are presumably not useful for expressing policy about EPG speakers. (?) All in all, if these things are true, do folks here have feelings about how advisable it is to implement policy in terms of AS-path expressions in 4Q94? Guesses about 3Q95? - --Dale - ---------- PS: After we get Dale's memory sorted out, it might be interesting to take this same question to BGPD. ------- End of Forwarded Message -------- Logged at Thu Sep 29 18:42:52 MET 1994 --------- From cengiz at ISI.EDU Thu Sep 29 18:42:13 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 29 Sep 1994 10:42:13 -0700 Subject: How trustworthy are existing BGP AS Paths? In-Reply-To: <199409291724.NAA20764@merit.edu> References: <199409291724.NAA20764@merit.edu> Message-ID: <199409291742.AA09993@chl.isi.edu> Jessica Yu (jyy at merit.edu) on September 29: > Dale, > > The reason for routes with different AS origins is not due to configuration > errors but routing arrangement between ASs. When two ASs speak IGP between > themselves but each BGPs with other ASs, such as the Michnet and UMnet > situation, this would occur. Anyother problematic ASpath scnerarios? When Michnet border router advertises a route for a destination in UMnet, does it use the ASPath "MichnetASno UMnetASno" or just "MichnetASno" or "UMnetASno"? (Perhaps UMnetASno = MichnetASno?). If it uses "MichnetASno", implementing policies at the AS level would not work. (Problem is at bad IGP-BGP interaction not becuase AS level policy implementation is inadequate.) Does this kind of IGP-BGP interaction happen in lots of places? Thanks. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Sep 29 19:50:52 MET 1994 --------- From jyy at merit.edu Thu Sep 29 19:50:47 1994 From: jyy at merit.edu (Jessica Yu) Date: Thu, 29 Sep 1994 14:50:47 -0400 Subject: How trustworthy are existing BGP AS Paths? In-Reply-To: Your message of "Thu, 29 Sep 1994 10:42:13 PDT." <199409291742.AA09993@chl.isi.edu> Message-ID: <199409291850.OAA27790@merit.edu> >When Michnet border router advertises a route for a destination in >UMnet, does it use the ASPath "MichnetASno UMnetASno" or just >"MichnetASno" or "UMnetASno"? (Perhaps UMnetASno = MichnetASno?). It will use MichnetASno. Since the Michnet router learns routes of UMnet via IGP, it does not need to and does not know "UMnetASno". So when you redistribute IGP routes to BGP route, the routes are all marked with MichnetASno as the origin. >If it uses "MichnetASno", implementing policies at the AS level would >not work. (Problem is at bad IGP-BGP interaction not becuase AS level >policy implementation is inadequate.) Yup. >Does this kind of IGP-BGP interaction happen in lots of places? Well, there are messages to bgpd saying that they see a lot of routes with different AS origin so it is perhaps not unusual. --jessica -------- Logged at Thu Sep 29 22:33:50 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Sep 29 22:33:04 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 29 Sep 1994 22:33:04 +0100 Subject: How trustworthy are existing BGP AS Paths? In-Reply-To: Your message of Thu, 29 Sep 1994 13:09:19 -0400. <199409291709.NAA19443@merit.edu> Message-ID: <9409292133.AA12802@mature.ripe.net> Dale, There is a few things about it. One is that if two ASes speak an IGP that cannot carry ASpaths (like the most used ones today) you loose the first AS if the second announces this in an EGP somewhere. Of course one only cares about this if the first one also announces this using an EGP somewhere. In cases where the first AS never announces this with an EGP, the AS is invisable and cannot be seen anywhere, so it may as well not exist. Second is the misconfigurationwith any network that connects two or more ASes. If both announce this, it'll appear as originated from both ASes. This is true for any link between two or more ASes (which includes DMZs). This in my view is misconfiguration, or you could argue that this network really is in multiple ASes, or perhaps even should not be routed. I can live with the second case, but in the first case I think this is weird network engineering. If there are two ASes they should run an EGP between the two, be it EGP itself or whatever. In the old days people would run IGPs between ASes because most IGPs have a better convergence times, but that no longer holds for current EGPs. The problems with AS paths (and the validity of them) has always been our problem with using paths in the ripe-81 context. However, the thing you mention is only about originating ASes and not necessarily concerns paths. If you want to do path based policy, you have to know a lot about the topology of the network, and you give away control of part of your policy. Because if you base a policy on a path that contains ASes that are some AS hops away, and that AS decides to change its config, you may end up loosing connectivity. However, we have had this discussion many a time, and it is mentioned more than once in ripe-81++. * Also, AS-Path expressions are presumably not useful for expressing * policy about EPG speakers. (?) Depends. Stubs EGP speakers are fine, as long as all next ASes along the way speak an EGP that can carry paths. * All in all, if these things are true, do folks here have feelings * about how advisable it is to implement policy in terms of AS-path * expressions in 4Q94? Guesses about 3Q95? I don't care really. People who specify their policy in terms of paths should know damn well what they are doing. If they don't, perhaps they deserve to be misconfigured because of it .... -Marten -------- Logged at Sat Oct 1 00:58:07 MET 1994 --------- From Tony.Bates at ripe.net Wed Sep 7 01:08:11 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 07 Sep 1994 01:08:11 +0200 Subject: Draft of RIPE81++ In-Reply-To: Your message of Wed, 07 Sep 1994 00:11:48 MDT. <9409062211.AA07926@rijp.ripe.net> Message-ID: <9409062308.AA19564@mature.ripe.net> Marten Terpstra writes: * * * Hold on, what is the point of a routing registry if you are not * convinced people will update the information? If one cannot convince * people to keep the routing registry up to date (ie if you do not give * them an incentive to keep it up to date) the routing registry is * useless. Partly correct information is worse than no information at * all. If you think this is true for the peer router, isn't this true * for any information people put in? The idea is that people work from * the routing registry to a configuration and not vice versa. This is * the only real incentive you can give people. * RIGHT RIGHT RIGHT !!!! Are we just dreaming of an RR utopia - I hope so. Marten articulates the point very well. Sometimes we need to force the use of the registry for what we want the registry to do. * But, let's not start a discussion on this, let's concentrate on the * things that need a decision. I just think that arguing that people * will not update the information is the wrong reason to have something * mandatory or optional. * Agreed. * * See you all in Lisbon. * * --Elise * * You should probably send in a registration form.... * Yep - we haven't got one yet (dont forget to send template to meeting at ripe.net). --Tony -------- Logged at Wed Sep 7 01:29:34 MET DST 1994 --------- From cengiz at ISI.EDU Wed Sep 7 01:29:01 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 6 Sep 1994 16:29:01 -0700 Subject: Draft of RIPE81++ In-Reply-To: <9409062052.AA00991@pepper.merit.edu> References: <9409061311.AA29253@dxcoms.cern.ch> <9409062052.AA00991@pepper.merit.edu> Message-ID: <199409062329.AA04265@chl.isi.edu> Hi all, I am quite new on this list. Here are my opinions on this issue. Perhaps most of my concerns have been addressed. First of all, I do not agree that a new attribute is necessary to support multi-exit discriminators. Why not just extend the as-in/out statements? If backward compatibility is the reason, the previous syntax can be made a special case. If ambiguity is the reason, there are simple solutions as proposed. I support that the specification of 0,1 or 2 border-routers are allowed. [see below] epg at merit.edu (epg at merit.edu) on September 2: > We are concerned that requiring the identification of the local > gateway and the remote gateway in the interas attribute has two > problems. The first problem is that of maintenance of the attribute. > If an AS is required to list both the local gateway and the remote > gateway, then the AS must update its registry information whenever > the remote AS makes any configuration changes. This could lead > to many inconsistencies within the database. I will use "br-edge" to mean border-router-to-border-router edge in the following. A br-edge can be identified with 1) two AS numbers if there is only one br-edge between two ASs 2) two AS numbers and one border-router address if there are multiple br-edges between the ASs, but each border-router is only connected to one border-router in the other AS 3) two AS numbers and two border-router addresses if there are multiple br-edges and a border-router is connected to two border-routers in the other AS. With what Tony proposes, ripe81++ allows specification of either 0 (with as-in) or 2 border-router addresses (interas-in). Elise proposes to allow also specification of 1 border-router address to cover case 2 above since it is helping in maintaining the databases. I have not seen the reason why it is necessary/useful to force specifying two addresses in this case. I have more important reasons to support specifying one addresses. [See below] > * 2) the mandatory nature of asin/out attributes if interas attributes are > * present Even if they are optionally present the semantics of such expressions are not clear in the document (at least July 94 version) and can be ambiguous. What is the semantics of the following policy: as-in: AS690 100 NOT ANY interas-in: L:foo AS690 R:bar 100 ANY (please forgive the syntax errors :-) Jean-Michel Jouanigot (jimi at dxcoms.cern.ch) on September 6: > Elise, I agree with you, there's no need to register information > you don't need, it's more difficult to manage, but as Tony points > out, why would anybody need this detailed information unless you > really want to configure a box with it, in which case you *need* > the local and remote addresses. You have a point. But the boxes are now getting more complicated:-) One such box is the Routing Arbiter Route Server. RS peers with many border routers. Hence, someone who peers with an RS may not (and does not need to) know addresses of other border routers. Multi-exit discrimination may be achieved if specification of one border-router address is allowed. Regards. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Wed Sep 7 10:37:46 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed Sep 7 10:37:36 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 07 Sep 1994 10:37:36 +0200 Subject: Draft of RIPE81++ In-Reply-To: Your message of Tue, 06 Sep 1994 16:29:01 PDT. <199409062329.AA04265@chl.isi.edu> Message-ID: <9409070837.AA08448@rijp.ripe.net> Cengiz Alaettinoglu writes * Jean-Michel Jouanigot (jimi at dxcoms.cern.ch) on September 6: * > Elise, I agree with you, there's no need to register information * > you don't need, it's more difficult to manage, but as Tony points * > out, why would anybody need this detailed information unless you * > really want to configure a box with it, in which case you *need* * > the local and remote addresses. * * You have a point. But the boxes are now getting more complicated:-) * One such box is the Routing Arbiter Route Server. RS peers with many * border routers. Hence, someone who peers with an RS may not (and does * not need to) know addresses of other border routers. Huh? Why would you in any case want to know addresses of border routers you do not peer with? An RS model is no different, and even the NEXT_HOP feauture does not change that. I cannot believe there is one example where you can configure a peering session without knowing both ends of the session..... Mind you, I personally do not really care whether we have one or two border routers from a purely syntactical point of view. I just want something that we can explain, and that people will use correctly and keep up to date. And in my view, anything that is optional makes it easier to make mistakes, or leave information out which would really be needed. The reason I am arguing is because in my view I have not read any convincing reason to make it optional. The only real reason for me would be if one could configure a peering session with one or two unknown addresses. -Marten -------- Logged at Wed Sep 7 16:56:53 MET DST 1994 --------- From epg at merit.edu Wed Sep 7 16:56:44 1994 From: epg at merit.edu (epg at merit.edu) Date: Wed, 7 Sep 1994 10:56:44 -0400 (EDT) Subject: Draft of RIPE81++ In-Reply-To: <9409062302.AA19527@mature.ripe.net> from "Tony Bates" at Sep 7, 94 01:02:45 am Message-ID: <9409071456.AA01230@pepper.merit.edu> Now, I know why I never joined a debate team.... >Tony Bates writes: > > epg at merit.edu writes: > * Jean-Michel and Tony, > * Thanks for your comments. Let me preface my following responses with > * a probably contentious statement (though I'm not looking for an > * argument nor trying to start a fight) - we probably wouldn't be having > * this debate if we had just modified as-in and as-out to optionally > * include multi-exit discriminators. Then there would be no need for > * interas-in and interas-out and there would be no need to translate > * from interas-in/out to as-in/out. But I acknowledge that you all do > * not want to modify as-in/out and therefore if we are to support > * multi-exit discriminators, we need to have a new attribute. > * > Well..perhaps you have a point here...not sure though.. as we have modified it > (it accepts netlists now). When we looked at it the only time MEDs were > used were in the interas scenarios though right ?. > > * Just wanted to say that because as I responded to all this, it > * seemed to me that we were trying to refine a kludge instead of focusing > * on what we had started out to describe. Probably just grumpy 'cause > * it's a nice day and I'm stuck inside. > > Now you are right about refining a kludge (IMHO somewhere we turned the whole > thing into a kludge). However, I think the focus is still > there of what (at least in my mind) interas is tying to define and it > is what is depicted in the example. How to document more than one inter-AS > conection between two ASes. > It's probably too late to go back to our innocent beginnings, but it would be nice to have one attribute - as-in/out which permitted the simple case (from AS accept otherAS) AND the extended case (from AS Lgateway Rgateway accept otherAS). The rules would be that it is illegal to have only one gateway registered, but you could register zero or two per as-in/out line. So much for my daydreams..... > * > * Guess, our thoughts on this are colored by working with folks like > * BARRNET which have always had at least two gateways that peer with > * our one gateway. BARRNET has then preferred to accept one set of > * nets at one router and the rest of the nets at another router. > * > But how does this not fit into all stated. Barrnet clearly has a general > policy (as-in/out) between Barrnet and AS690 (the union the two sets of > routes) and clearly has a policy describable by the interas attributes ? > All I was trying to show was that there is a case where you want to distinguish between two local entities (border routers) and their policies in relationship to a single remote entity (the remote border router). Yes, you need to know the remote routers ip address to make a configuration file (duh!), so from a local policy perspective, it's not necessary to identify the single remote router. Not a big deal - just a preference. > * > > I dont agree on the inconsistencies. The type of people who will use > * > > this attribute will know what their peers AS routers are. Lets face it > * > > who runs there BGP peering without configuring the remote peer address? > * > > > * > * Whereas someone will always configure their peer router, we're not > * convinced that folks will show the same attention to updating the > * routing registry. > * > > Well then we are dead in the water then. How do we use tools without both ends > ? - How do people understand the policy with ESP of the topology ? > Even worse - if we assume people dont register except their info. why > both at all ? > Actually, I was basing my opinion of the willingness of folks to update a registry on the experience of SRI NIC, the InterNic and you all. Seems like it's difficult to keep information current (I agree on the necessity), and if there were less updates mandated for the local person who didn't care if the remote end changed since it didn't change the local person's policy, then we would have less chance of inconsistencies. > * > > Sure but this is not mandatory for solving the ambiguity. > * > > > * > * Whoops, maybe I had a wrong assumption here. It seemed to me that > * the local and remote gateway characteristics of the interas-in/out > * attribute had been changed to mandatory (whereas they used to be > * optional) because with the selected syntax listing one gateway > * only would be ambiguous. Listing no gateways or two gateways is > * unambiguous; it's only if you are permitted to list only one gateway > * that there is no way to distinguish whether it is a local gateway or > * a remote gateway. Have I made the incorrect assumption? > * > Nope - you are not under a mis-conception. They are both mandatory for reasons > above. They can be changed if people agree and I can just be on my own on this > one (no problem with that). But, let me re-iterate, they are not mandatory to > solve the ambiguity problem or to force our ordering. They are mandatory so the > provider documenting policy knows both end of the link. He has to know this. > How many people have a passive BGP connection that does not care who connects > to them ? > OK, so what is illegal is to list only one gateway. Can we just make it illegal to list only one gateway, but to still have the optional? > * > Elise, I agree with you, there's no need to register information > * > you don't need, it's more difficult to manage, but as Tony points > * > out, why would anybody need this detailed information unless you > * > really want to configure a box with it, in which case you *need* > * > the local and remote addresses. Well, I don't know the answer, > * > but you probably have such a case, otherwhise you would not ask > * > for it :-) What I would propose is to: > * > > Wait though by proposing this we have them optional - Question is can you give > a case ? and even if it exists are they changing so often and will be > maintained by providers who wont update (hard to answer but important to > issue). > And she repeats herself yet again....the point I was trying unsuccessfully to make is that if the remote gateway changes (in my example) it is a configuration change but not a policy change so therefore the local person may not feel that it is urgent to update the registry. If the local person uses the registry to generate configuration files for the local routers, you can bet your bippy that the registry will be updated. If not, all bets are off. > * > 1- Keep the ordering as it is in Ripe-81++ (to be close to the > * > as-in syntax), > * > > * > * OK > * > * > 2- Accept the Local and remote router info to be optional > * > > * > * OK > * > * > 3- Solve the parsing issue by adding what Jessica proposed (L:... R:...) > * > > * > * OK > * > My last try on this. It is obvious to solve ambiguity - there are a million > different ways - I am not making them mandatory for this reason. The question is > how we will use them if they are optional and should we make the assumptionthat > users of the registry only care about there own data. Also, please tell > me how this all fits (in terms of reasoning for optional is we have only > a remote gateway registered - this just turns the whole argument upside down). > Have to attend a meeting in about 2 minutes...will reply to this question after the meeting...do I have to continue, or can we agree on zero or two, with one being illegal????? > * > Well, I'm not sure I do agree with what I write, but if I can get a > * > consensus ... > * > > Me either (referring to Jimi suggested resolution) and I would like > to see if we do need to go to consensus on this that this is decided at the > RIPE meeting. > It would be nice if we could come to some conclusion...after all we are really the only ones who argue in public :-) Yikes - this note goes on forever....have to run...will try to respond to the other zillion points later. --Elise -------- Logged at Wed Sep 7 20:06:25 MET DST 1994 --------- From cengiz at ISI.EDU Wed Sep 7 20:05:07 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 7 Sep 1994 11:05:07 -0700 Subject: Draft of RIPE81++ In-Reply-To: <9409070837.AA08448@rijp.ripe.net> References: <199409062329.AA04265@chl.isi.edu> <9409070837.AA08448@rijp.ripe.net> Message-ID: <199409071805.AA04304@chl.isi.edu> Marten Terpstra (Marten.Terpstra at ripe.net) on September 7: > Huh? Why would you in any case want to know addresses of border > routers you do not peer with? An RS model is no different, and even > the NEXT_HOP feauture does not change that. I cannot believe there is > one example where you can configure a peering session without > knowing both ends of the session..... I agree with what you say in the above paragraph: The border routers which peer with an RS know the address of the RS. I just want to clarify a point though. In specifying policies, RS will be transparent. That is if AS100 and AS200 peer with an RS, administrators of AS100 specify policies for AS200, not for RS. If multi-exit discrimination is allowed in this case, there are two options for administrators of AS100: 1) only specify local border router, i.e. interas-in: from AS200 local-address - ... 2) use RS's address, i.e. interas-in: from AS200 local-address rs-address ... There are 4 problems with the second option: 1) RS is not completely transparent. (though RS' AS is). 2) It is confusing since RS is not in AS200. 3) If the address of the RS changes, many changes by many administrators will be necessary in the database even though policies stay the same. 4) If it was actually necessary to specify two addresses (i.e. one address in AS100 and one in AS200) in expressing policies (e.g. if both ASs has two connections to RS, and they want to discriminate on each connection), option two can not handle this. Regards, Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Sep 8 18:19:42 MET DST 1994 --------- From Tony.Bates at ripe.net Thu Sep 8 18:19:04 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Thu, 08 Sep 1994 18:19:04 +0200 Subject: Draft of RIPE81++ In-Reply-To: Your message of Wed, 07 Sep 1994 11:05:07 PDT. <199409071805.AA04304@chl.isi.edu> Message-ID: <9409081619.AA18635@mature.ripe.net> cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * Okay, firstly I would like to say that clearly the RS is a special case and may in fact not fit into the generalised routing registry description and this not a basis for the current discussions. Although I am not convinced just yet. Let's look at what you say. * I agree with what you say in the above paragraph: The border routers * which peer with an RS know the address of the RS. I just want to * clarify a point though. * * In specifying policies, RS will be transparent. That is if AS100 * and This is very much how you wish to interperate and implement a route server. In protocol terms the RS in certainly not transparent. In terms of policy yes but you still should express your policy with respect to the RS in terms of the policy it can provide. * AS200 peer with an RS, administrators of AS100 specify policies for * AS200, not for RS. If multi-exit discrimination is allowed in this * case, there are two options for administrators of AS100: * 1) only specify local border router, i.e. * interas-in: from AS200 local-address - ... * 2) use RS's address, i.e. * interas-in: from AS200 local-address rs-address ... * Right but is more like interas-in: from AS-RS local-address rs-addres or even as-in for that matter. Now this may look odd semantically but is correct. The bottom line is this where the routing information is derived from. The RS has a policy to both AS200 and AS100. Of course if it is multiple image this is hard to express in ripe-81++ (although can be kludged). However, remember ripe-81++ is modelled on the premise of destination based policy decisons and not making use of source for policy which is what the multi-image RS is doing. * There are 4 problems with the second option: * 1) RS is not completely transparent. (though RS' AS is). No.....Wrong way round I think. RS AS will be there or are you gonna break the BGP protocol ? * 2) It is confusing since RS is not in AS200. No but if expressed in terms of RS-AS it is not confusing. * 3) If the address of the RS changes, many changes by many * administrators will be necessary in the database even though * policies stay the same. And what is the problem ??? This is no differnet at any DMZ and a router changes its address. Why the "pilot RS" we have at Mae-east has 12 peers, if I change the address I inconveience 12 providers but thats life - the Internet is dynamic and volatile and we shouldn't pander to making things like this especially easy. The RR (yes RR - not RS) should be an integral part of all Internet service and to be quite honest if you want the RS to fly using a general RR you want to make it important that providers respond to changes and realise how import the RR is. I think we should be careful when looking at the RS in general. Clearly much more understanding of what is needed in terms of the policies wanted from the RS is in order. However, the basic argument changes very little in terms of whether this is optional or not. --Tony -------- Logged at Thu Sep 8 19:17:37 MET DST 1994 --------- From dsj at merit.edu Thu Sep 8 19:17:34 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 8 Sep 1994 13:17:34 -0400 Subject: A Modest COMMunity Proposal Message-ID: <199409081717.NAA29309@merit.edu> Marten, Tony, I have a very modest proposal for the COMMunity-handling code, which has a slightly complicated agenda behind it. I believe this would be an implementation detail which would have no implication for any current document. PROPOSAL: That the RIPE DB code that reads COMMUNITY files be written in such a way that only the IP/LEN at the beginning of each line be read; that anything after that initial IP/LEN (and trailing whitespace) would be considered as a comment by existing code. COMPLICATED RATIONALE: We have this "DBSELECTOR" thing that we need to implement in order to be able to do net-based policy (particularly for AS690). One possible architecture for the DBSELECTOR data format would be to make it an extension to the COMMunity object. The current definition of the COMMunity object and its usage would not change (except for declaring anything past the first whitespace character to be of no interest to the code). Any current COMMunity file would fulfill its present funciton without changes. Those who had need, though, could add text tokens to the COMMunity lines, which could be "grep'd" by the DBSELECTOR function. Specifically, I could create a COMM_AS690 file with the following format: # # COMM_AS690 - Community Definition for ANSNet/NSFNet # # Format: IP/Len [metric:AS(NSS) [metric:AS(NSS)] ... ]] # 6.0.0.0/8 1:568 2:19 7.0.0.0/8 1:701(136) 2:701(134) ... Our DBSELECTOR syntax could then be used to produce sets of networks, one set for each metric:AS(NSS) token that exists in the file. If we don't have a feature that gives us this kind of functionality, we may be forced to create 300+ specially-named COMMunity files just to be able to represent AS690 policy. (And another 300+ for MCINet, and another for SPRINTNet, ... ) ----------------------------------- If you and Tony (and Daniel, when he gets back) consider this at all reasonable, we could expand the discussion to more detail. For instance, this information also really needs to be copied into the public database somewhere. Currently, for AS690, it is in the about-to-be-retired nsf-in attribute. If we used the 300+ community approach, it would end up in the Route object, as a series of community names: Route: 6.0.0.0/8 Communities: COMM_AS690_1:568 COMM_AS690_2:19 COMM_ASMCI_1:568 ... It might be useful to create a new Route attribute specifically for these AS-specific purposes: Route: 6.0.0.0/8 Communities: HEPNET COMM_AS690 COMM_ASMCI COMM_Details: COMM_AS690 1:568 2:19 COMM_Details: COMM_AS 1:567 2:53 There are a number of fundatmental issues which tie into this: who owns the data, how is it changed, (how often is it changed; how expensive is that operation), whether that info is fully public (e.g. contained in the ftp of ripe.db), etc. This is only one of a number of possible implementations that I think it would be good for everyone on this list to discuss (presumably mostly after the Lisbon meeting, since this would not be part of RIPE-81++). But since you are finishing up the next release of the code, I thought I'd suggest the addition of the one inoccuous line to the code that reads COMMunity files that would keep this approach from breaking things in the future. Thoughts? --Dale -------- Logged at Thu Sep 8 21:54:52 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu Sep 8 21:54:41 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 08 Sep 1994 21:54:41 +0200 Subject: A Modest COMMunity Proposal In-Reply-To: Your message of Thu, 08 Sep 1994 13:17:34 EDT. <199409081717.NAA29309@merit.edu> Message-ID: <9409081954.AA11124@rijp.ripe.net> * PROPOSAL: That the RIPE DB code that reads COMMUNITY files be written * in such a way that only the IP/LEN at the beginning of each line be read; * that anything after that initial IP/LEN (and trailing whitespace) would * be considered as a comment by existing code. * * * * COMPLICATED RATIONALE: We have this "DBSELECTOR" thing that we need [..] I sort of understand the rationale. I'll have to go through it in a bit more detail though especially in light of: * But since you are finishing up the next release of the code, I thought * I'd suggest the addition of the one inoccuous line to the code that reads * COMMunity files that would keep this approach from breaking things in the * future. The next release of the code will no longer work with the guardian files stuff the way they do now. I am sorry we have not been too informative about this, but this sort of came out of an authorisation document written only last week. Some bits were agreed at the RIPE meeting. What it basically comes down to is that each and every object can be properly maintained, ie there is some authorisation done before an object can be updated. For routes, the usual maintainer would be the person currently being the guardian. They insert the route, so they change the object, and them only. Communities are no longer guarded as such, but are being put in a special position, so that every change to a route that affects communities, all community guardians receive a notification of this change. For a bit more detail, you should have a look at: ftp.ripe.net:ripe/drafts/ripe-auth.{txt|ps} ftp.ripe.net:ripe/drafts/db-trans.{txt|ps} The first explains the general authorisation model and the way it can replace the current guarded attributes and guarded objects mechanism (which I always considered an interim measure), and the second provides a transition plan (mostly for us) to move to ripe-81++ and classless database with all consequences involved. These docs have just been finished so you probably have not seen them yet. Mind you, they will have to be agreed at the RIPE meeting next week. We see little problems though. In the meantime, let me think about the rest of your mail. If you just want a quick change to skip everything in the cleanup after you have read the prefix/length, that is easy. In cleandb.pl in the routine readguard(), some 20 lines down from the top or so, you'll find the regex substitution s/\s*$//; which removes all trailing spaces. Change that to something like: s/^(\S+).*$/\1/; and it should ignore everything after the first string. Come to think of it, it does not even strip leading spaces. Bug ;-( Better make that: s/^\s*(\S+).*$/\1/; that should work. The rest of the community detail stuff I'll have to read better first. Adios, -Marten -------- Logged at Thu Sep 8 22:02:29 MET DST 1994 --------- From rlr at merit.edu Thu Sep 8 22:02:23 1994 From: rlr at merit.edu (Rick Riolo) Date: Thu, 08 Sep 1994 16:02:23 -0400 Subject: A Modest COMMunity Proposal Message-ID: <199409082002.QAA09879@toad.merit.edu> I just copied these to merit:/u/rlr ... (the ps versions) - r -------- > > ftp.ripe.net:ripe/drafts/ripe-auth.{txt|ps} > ftp.ripe.net:ripe/drafts/db-trans.{txt|ps} > -------- Logged at Thu Sep 8 22:39:30 MET DST 1994 --------- From Tony.Bates at ripe.net Thu Sep 8 22:39:05 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Thu, 08 Sep 1994 22:39:05 +0200 Subject: A Modest COMMunity Proposal In-Reply-To: Your message of Thu, 08 Sep 1994 21:54:41 MDT. <9409081954.AA11124@rijp.ripe.net> Message-ID: <9409082039.AA18911@mature.ripe.net> * * ftp.ripe.net:ripe/drafts/ripe-auth.{txt|ps} * ftp.ripe.net:ripe/drafts/db-trans.{txt|ps} Just to reiterate what Marten says. You should take a look at this as the whole authorisation and guarian mechanism will change. The nice thing is if you wanted to use this scheme we are to use you do not have the major transition headache we have to go through with this which is certainly non-trivial due to having amoung other things 126 guardian accounts actually being used ;-(. However, in the long term this will be well worth it. --Tony. -------- Logged at Fri Sep 9 00:05:38 MET DST 1994 --------- From epg at merit.edu Fri Sep 9 00:05:34 1994 From: epg at merit.edu (Elise Gerich) Date: Thu, 8 Sep 1994 18:05:34 -0400 Subject: the four points Message-ID: <199409082205.SAA25185@merit.edu> Can we try to summarize where we are with the four points that started this discussion: 1) the mandatory nature of the gateway statement in the interas attribute Jean-Michel made a suggestion which was: a) the ordering of interasin/out remains as documented in RIPE 81 ++ b) the local and remote router info is optional c) solve the parsing by adding "L:" and "R:" Do we all buy into that? 2) the mandatory nature of asin/out attributes if interas attributes are present Merit has presented reasons for leaving these both optional. Will both as-in/out and interasin/out remain optional? 3) the proposal for an asname attribute We have all agreed to add this, correct? 4) the proposal for a change time attribute This is a DB working group issue so it will be addressed in another forum. Is this an accurate summary of our discussion so far? Thanks. --Elise -------- Logged at Fri Sep 9 15:17:00 MET DST 1994 --------- From jyy at merit.edu Fri Sep 9 15:16:49 1994 From: jyy at merit.edu (Jessica Yu) Date: Fri, 09 Sep 1994 09:16:49 -0400 Subject: Draft of RIPE81++ In-Reply-To: Your message of "Mon, 05 Sep 1994 14:01:04 +0200." <9409051201.AA14700@mature.ripe.net> Message-ID: <199409091316.JAA18014@merit.edu> > * We were in agreement until a few weeks ago that these would be optional > * and to make them mandatory simply to resolve a syntax problem when > * other solutions are available is a loss > * >Well perhaps it may have seen that way but this is probably due to me >copying in Jessicas text without checking properly. Tony, it sounded like I just sneaked text in :-) but actually we really agreed to make the gateway field in interas-in/out optional during our meeting at Toronto. (after a couple of bottles of beer ?:-)). Below is the message you sent out summaring the result of the meeting. Point 1. reflects the agreement. Thanks! --Jessica Date: Wed, 27 Jul 1994 23:37:31 +0200 To: rr-impl at ripe.net From: Tony Bates Subject: Summary of small meeting with merit of the last ripe-81++ issues Replied: Wed, 03 Aug 1994 12:38:30 -0400 Replied: jyy at merit.edu Replied: Tony Bates Return-Path: tony at ripe.net X-Phone: +31 20 592 5064 X-Fax: +31 20 592 5090 Sender: Tony.Bates at ripe.net Here follows the actions and issues resulting from a small meeting today here in Toronto. 1. The optional parts as per Jessica messages would be made clear in the interas-in/interas-out syntax. 2. Jessica will submit the changes to the syntax in the pref-type part to clear up that the pref-type is not fixed in the future. 3. The ordering will be left to Jimi to decide on return but would remain as is in the ripe-81++ draft with the same statement on top whne next sent out. 4. Jessica will send the diffs to 1 and 2 out to rr-impl by Tuesday next week at the latest. 5. Tony will fold these in before the end of that week and send out the new draft. This will be the last changes made other than the possible ordering change. --Tony. -------- Logged at Fri Sep 9 23:50:20 MET DST 1994 --------- From cengiz at ISI.EDU Fri Sep 9 23:49:49 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 9 Sep 1994 14:49:49 -0700 Subject: interas-out Message-ID: <199409092149.AA04869@chl.isi.edu> By the way, the format of interas-out on page 45 and format used in the examples do not match in the placement of . In my program, I am assuming the one in the examples since that one is consistent with interas-in. Please let me know if the other format is the right one. Regards. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Fri Sep 9 23:59:29 MET DST 1994 --------- From Tony.Bates at ripe.net Fri Sep 9 23:59:17 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Fri, 09 Sep 1994 23:59:17 +0200 Subject: interas-out In-Reply-To: Your message of Fri, 09 Sep 1994 14:49:49 PDT. <199409092149.AA04869@chl.isi.edu> Message-ID: <9409092159.AA23607@mature.ripe.net> cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * * By the way, the format of interas-out on page 45 and format used in * the examples do not match in the placement of . In my program, I * am assuming the one in the examples since that one is consistent with * interas-in. Please let me know if the other format is the right one. * * Regards. * * Cengiz * Cengiz, I noticed this the other day and made the correction to the current text but didn't feel it warrented a new update until we resolved the other issues. Anyway, find below the "current" text for interas-out --Tony. interas-out: Format: to [] announce The keywords to and announce are optional and can be omit- ted. The definitions of , , ripe-1nn.txt August, 1994 - 54 - and are identical to those defined in interas-in. is optional and is defined as follows: (=) It should be noted the parenthesis ``('' and ``)'' and the keywords of ``'' must be present for this metric to be valid. currently only supports "metric-out". It could be expanded to other type of preference such as TOS/QOS as routing technology matures. can take one of the following values: is a pre-configured metric for outbound routes. The lower the cost the more preferred the route. This value is literally passed by the routing protocol to the neighbor. It is expected that it is used there which is indicated by pref=MED on the corresponding interas-in attribute. It should be noted that whether to accept the outgoing metric or not is totally within the discretion of the neigh- bor AS. IGP This indicates that the metric reflects the ASs internal topology cost. The topology is reflected here by using MED which is derived from the AS's IGP metric. NOTE: Combinations of IGP and should be avoided for the same destinations. CAVEAT: The metric-out values may well be enhanced in the future as more interas protocols make use of metrics. Examples: interas-out: to AS1104 192.87.45.254/32 192.87.45.80/32 (metric-out=10) announce AS23 AS10 interas-out: to AS1104 192.87.45.254/32 192.87.45.80/32 (metric-out=15) announce AS10 interas-out: to AS1103 192.87.45.254/32 192.87.45.80/32 (metric-out=IGP) announce ANY Status: optional, multiple lines allowed -------- Logged at Mon Sep 12 20:53:49 MET DST 1994 --------- From cengiz at ISI.EDU Mon Sep 12 20:53:07 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 12 Sep 1994 11:53:07 -0700 Subject: semantics ambiguity with interas-in/out: clarification sought Message-ID: <199409121853.AA05050@chl.isi.edu> Tony Bate (Tony.Bates at ripe.net) on August 26: > Descriptions of interas policies do not replace the global pol- > icy described in as-in, as-out and other policy attributes which > always describes the global policy between the two ASes. The > interas-in/out attributes only specify local variations to the glo- > bal policy described in the other attributes. If the global policy > mentions more routes than the local policy then local preferences > for these routes are assumed to be equal for all links. as-in: AS1 pref1 polexpr1 interas-in: AS1 lid rid pref2 polexpr2 with the above description, the routes imported through (rid, lid) connection is: polexpr1 or polexpr2 with the following preferences: pref2 polexpr2 pref1 (polexpr1 setminus polexpr2) Is this right? (If it is, including above more formal formulation might help more implementors). Eg. as-in: AS1 100 AS2 AS3 AS4 interas-in: AS1 lid rid 90 AS2 AS4 AS5 that is import routes in AS2 AS3 AS4 AS5 with the following preferences 90 AS2 AS4 AS5 100 AS3 Is this right? More complicated E.g. as-in: AS1 100 AS2 AS3 AS4 interas-in: AS1 lid rid 90 (AS2 AS4 AS5) AND NOT AS3 Note that "(AS2 AS4 AS5) AND NOT AS3" is equivalent to "AS2 AS4 AS5". Hence this example is identical to previous one and there is no way to avoid importing routes in AS3. Actually with the current definitions there is no way that the local policies can be a restricted version (subset) of global policies. (Unless the global policy is "NOT ANY" and everything is done through local policies. Of course, this is not intended.) Is this right? Hence, Merit's example: epg at merit.edu (epg at merit.edu) on September 6: > Guess, our thoughts on this are colored by working with folks like > BARRNET which have always had at least two gateways that peer with > our one gateway. BARRNET has then preferred to accept one set of > nets at one router and the rest of the nets at another router. can not be implemented using interas-in/out unless the global policies of BARNet is accept NOT ANY and the local policy over one connection is to accept the first set of networks, and over the second connection is to accept the second set of networks. The simple fix to this problem is that the local policies replace the global policies. That is the routes imported through (rid, lid) connection is: polexpr2 as opposed to polexpr1 or polexpr2. This is a VERY SIMPLE solution. No confusion for implementors or administrators. This fix makes the interas-in/out policies more global which some of you do not like. To me, interas-in/out policies are as global as as-in/out. Any thoughts. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Wed Sep 14 19:23:44 MET DST 1994 --------- From dsj at merit.edu Wed Sep 14 19:23:28 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 14 Sep 1994 13:23:28 -0400 Subject: Communities in RIPE-81++ Message-ID: <199409141723.NAA06254@merit.edu> Marten, Tony, Thanks for the pointers to "Authorization and Notification of Changes..." and "RIPE Database Transition Plan". The transition plan is nicely detailed, and I really like the authorization options you've built in. I'll follow up with more minor comments about the texts, but I've got one big confusion about what is happening with the Communities (especially the "guarded attribute" processing for Communities). Here's my best reading so far: - Community objects continue to exist, and have the benefit of the new Maintainer support (including authorization checking) - Community files continue to exist in nearly their current format. The entries in the Community file need to be changed to refer to the prefix/length notation of Routes rather than the dotted quad IPs of Inetnums, and need to be converted to refer to what is actually registered as Routes (e.g. to reflect the level of aggregation registered by the Route objects). - The process will still exist where all the Community designations in the Inetnum or Route objects are deleted each night, and are replaced by new Community designations generated from the contents of the Community guardian files. Users can still submit new Inetnum/Route objects specifying Communities that they do not actually belong to; these are corrected only during nightly processing (though the new text specifies that a message will be sent immediately to the Community maintainer). Have I got this right? If so, I have the following comments about the text in the papers: > [Transition] 3.1 Guarded Attributes: > > As explained in [4], the current procedure for guarded attributes > is that guardians maintain files on the NCC database machine, from > which guarded attributes are added to objects to ["in"?] the database. > Although this has worked reasonably well for over a year, it can > be solved with a more general authentication and notification scheme. > This scheme is explained in [2]. ... Would it be more accurate to replace "it can be solved" with "the authentication portion of guarded attribute handling can be solved..."? As is, the text sounds like you're throwing out the whole idea of guardian files. > The introduction of the "route" objects in the RIPE database (see > below) removes the necessity of guarded attributes in their current > form. The primary reason for having guarded attributes (authenticity > guarantees becaue of their operational impact) can be solved by the > general authentication scheme. It seems to me this is true for the "Origin"/"Aut-Sys" guarded attributes, since they can now be contained in a Route object that is entirely owned (at least usually) by the same group that owns the AS. But it is not true at all for Communities. Communities still need to be owned by separate maintainers, and the Community designations spread over all of the Route objects need to be controlled by people other than the owners of the Route objects. This is not affected by the new general authentication scheme. > [Transition] 5.1.3 After B2 > > Change > Guardian file mechanism is no longer needed and disabled Huh? "...is disabled for Inetnum Aut-Sys attribute" ? > [Authorization] Special Rules in the Routing Registry > > ... However in order to support the necesary routing coordination, special > rules apply to the Route object: Whenever a Route object is created or > deleted or the Comm-list attribute changes, the guardians of all > communities and ASes referenced by the old and new objects will be > notified in addition to the normal notifications. This rule ensures > that community maintainers have retroactive control over community > membership and that ASes get notified if someone else adds a route > originated by them. This "retroactive control" consists of: 1) RIPE software will automatically delete unauthorized COMM designations overnight. 2) They could call the person and who added themselves to the COMMunity and ask them to remove the designation. 3) They could decide that the addition is ok, and add the new route to their Guardian file, thereby approving the change. Is this correct? ---------------------- As we build a "PRConfig" capable of producing GateD files for AS690 from the Routing Registry, we need the ability to store multiple AS:Metric designators for 40K+ nets. (Essentially the information that was contained in the old nsf-in attribute, though the new solution needs to scalable to multiple networks). The option of embedding 100K+ network numbers (40K * 2.3) directly in AS-in and AS-out lines doesn't sound appealing or readable. We've played with the option of using 300+ Community files with names like "COMM_AS690_1:200", though that also seems awkward. My message last week suggested a tiny change to the Community Guardian file description ("consider everything after the first blank to be a comment") that we could use with a DB_SELECTOR designation to store this informaion in a *single* Community file that would be owned by the AS generating the configs. The features we need are: 1) Maximally conformant with RIPE-81++ (and related documents) 2) Minimally unreadable (e.g. no 40K+ -token AS-in lines) 3) All information is part of the Global Routing Registry. (If it isn't, then we haven't really registered our policy globally, and it would not be possible for anyone to build tools (like prtraceroute) that could really tell if packets were taking the right paths or not). [4) Preferably, a security system that does not allow any user to register himself as part of your routing base for up to 24 hours, at his will.] As I understand it, the guardian files themselves are not part of the "Public Database": if you ftp ripe.db you do not get them, and they are not available via whois. Instead, you get that same information registered as "COMM" tokens spread over all of the Inetnum or Route objects. This is a nice solution for the "Public Database" problem, except for the overnight delay in having that information security- checked and updated. There are some reasonably easy ways to fix the technical limitations here (at least for the interactive servers), such as indexing the community guardian files and generating the COMM lists for each route whenever the Route is queried. (Laurent has code much like this working now in alc, and Rick has the same functionality built into a modified RIPE whoisd). (ftp access of the whole database would still require periodic generation, however). There could also be some very clean implementations of output for this, as well. If communities are used as is, each Route object will be tagged with multiple Community tags: comm-list: COMM_AS690_1:1800 COMM_AS690_2:1879 With an expanded Community guardian file (for use with DBSelector), there could be a designated format for this in the Route object, e.g.: comm-list: COMM_AS690( 1:800 2:1879 ... ) comm-list: COMM_AS999( xxxx ) ... (This becomes design of the "experimental" DB_SELECTOR...) ---------------------- I've strayed a bit here from just the text of the draft documents. We are in the process of building such a family of configuration generation tools now (can we coordinate with you on this?), and we very soon will have to decide on a representation for storing and using these massive net lists within a RIPE-81++ registry. This depends partly on understanding the coming code (Rick expects to be porting Marten's release as soon as it is out), and partly on finding ways that can be made to work within the current architecture. Any suggestions for us? :-) --Dale -------- Logged at Wed Sep 14 23:07:38 MET DST 1994 --------- From dsj at merit.edu Wed Sep 14 23:07:34 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 14 Sep 1994 17:07:34 -0400 Subject: Transition Draft Comments Message-ID: <199409142107.RAA23931@merit.edu> Marten, I didn't copy the list on my message because I thought most of my comments were superficial. But your answers weren't superficial, so I've added the list. --------------------------------------------------------------------------- > From marten at ripe.net Wed Sep 14 15:53:07 1994 > To: "Dale S. Johnson" > Cc: Tony.Bates at ripe.net, daniel at ripe.net > Subject: Re: Transition Draft Comments > From: Marten Terpstra > > > * More notes, this time on your excellent "Transition" draft: > > Hi Dale, we appreciate your comments and suggestions. I am halfway > through your previous comments, but let me start with this one. > > * p 10: Automatically generating the aggregate representation of a block > * assumes that the user will use the aggregation you come up with. This > * is more important than it might otherwise be because you state elsewhere > * that nothing should be routed without the exact route being registered > * in a route object. If there are folks that are still announcing classfully, > * this will misrepresent their situation. > * > * [Then again, maybe this is good "encouragement", and a better precdent > * that generating the classful route objects for them?? But maybe you > * need more transition planning then about getting the auto-generated > * aggregates into sync with what is really going on in the routing > * tables] > > The reason why we do this is to bootstrap the amount of routes into > the database. Perhaps we should be a bit more clear to say that after > generation, they should check whether the routes generated are > actually the routes they announce. I think we should indeed put some > text in there. > > * Smaller Stuff: > * > * p2: Don't you want to declare an error where an aggregate prefix is > * inconsistent with its length (rather than quietly truncating some > * bits?) > > Not sure. We definately do for updates. I find it a bit harsh for > queries. Proper documentation should take care of the "quiet > truncation" I think. Perhaps a warning message that the message was > truncated? I am not sure. > > * p4: Getting back something other than what you requested by a whois query > * is probably usually ok, but you may want to support an "exact matches only, > * please" flag on whois. > > You are right. This was also suggested by some people in the meeting > yesterday. I will have to see in the code how easy/difficult this is > to do. I think it should not be too hard. > > * Last sentence of p4; also section 5.4: The text about updating tools to > * use the new database seems to leave out one of the most important audiences: > * the masses of folks who are not writing tools but who have picked up old > * copies of tools and are just running them. > > Very true. We should make a note of this in the document. We will make > sure all our "ftp-able" tools will be up to "standard". > > * p4: "Changes to tools that make use of the database server have to be > * made before that time." ADD: "All users of current versions of these > * tools need to replace their copies of the current tools with the new ones". > * You could have a similar section (5.5?) on page 16: One set of tasks > * for people who are writing tools (e.g. adjusting to the new formats); > * another set of tasks for people who just use those tools. Perhaps a task > * for someone of *identifying* the people who are using old versions. > * > * On that idea: If you move to a dbserver approach (can we offer you one?), > * how about "version" command that would automatically be issued by all > * tools to the server. When the next incompatible round of tool changes > * comes up, the server could be set to tell the clients to print a message > * saying "This tool is obsolete because of XYZ change: obtain a new copy > * of the tool from ftp..." > > Yep. This was our idea as well. First implementation we would do is > very basic; an option to ask the server what options it supports. That > can be worked out to something what you describe. Dbserver is another > thing I will have to look at.... The current database server also > understand versions and types of clients, but is currently only used > for logging purposes. > > * p 6: Guarded Attributes: see my overlong message about Communities. > * Guarded Attributes are *not* replaced by the new authentication. > > Yes they are. I'll explain in more detail tomorrow morning when I > reply to the other mail you sent. It was also clear from the meeting > that esp that bit needs some different wording and better explanation. > > * 5.1.3: After B2: "Change; Guardian file mechanism is no longer needed > * and disabled". I believe this is not true: see my COMMunity memo. > > Again, I will clear this up tomorrow. > > * ... "Align any locally stored objects with the split objects". Dale does > * not know what "locally stored objects" means. My ignorance? > > "locally stored objects" are basically the files or databases or > whatever people have on their own machine and use to update the RIPE > database. Many people have a database server running for their own > data, and use that data to update the RIPE data. We just want to make > sure whenever we change something, they should do the same with the > information they keep locally. Ah, "copies of RIPE information that may be stored on local machines". > * 5.2 Local Registries - Again, Dale doesn't know what "Local Registries" > * are. Are these the "Mini-RIPEs?" Will others be confused? > > ;-) We should change this to Local Internet Registries. This should be > a familiar term for all involved. I'm afraid I'm still blinking. The text under the title says "This is the group who maintains 'inetnum' objects. They will see the consequences of the 'inetnum'/'route' split and will be able to use the new authorisation scheme." It sounds like this is "All NSPs who submit objects to the RIPE database", though the phrase "Local Registries" (or even "Local Internet Registries") sounds to me like they have to be running some kind of software locally and probably making some kind of server access available. I suspect this may be something that is so common a usage at the RIPE meeting that everyone knows what it means, but as someone who has never been to one of those meetings it sounds like distributed places running server software. > > * p15: > * > * 5.2.2 "Now possible to store multiple "inetnum" objects covering the > * same address space at different levels". Add: "though this should > * be extremely rare. See the RIPE-81++ Section 5: The Route > * Object." > > No it is not rare. Better yet, it'll be very common. Probably not so > much for routes, but definately for "inetnum:" objects. They contain > *only* allocation information by then. As the section on "querying the > database" says, we will insert into the database 193/8, 194/8, and > 193.1/16, 193.2/16 etc to show the IP address delegation/assignment > chain. All assigned 193 and 194 nets will appear at least 3 times in > the database in different "inetnum:" objects. Again, this line says > "inetnum" not "route". Ah, I was thinking too much about the Route objects, and missed the fact that it clearly says "inetnum". > > * Question: is it true that this ONLY happens in the case of Proxy > * Aggregation? If so, that might be worth saying. (Yes, I know, this > * was Merit's issue...) > > For routes you can basically have multiple route entries as well. > Routes originated from different AS's, more specific routes of a > bigger aggregate being used (which can be very valid), routes that are > in the registry but carry a "withdrawn" attribute, you name it. For > routes it will be less likely, but not at all in rare or exceptional > cases. Ah, you are right that there could be one active instance of a Route, and one "withdrawn" registration for that route for every NSP that the customer had jilted. I hadn't thought of that. I wonder if we have a fundamental nomenclature problem, though, about what a route is? I'm used to thinking of a route as the combination of the dotted-quad and the mask, so that "193.0.0.0/8" and "193.0.0.0/24" are different routes. Under this definition, you would still only have one active registration of a route at one time, except for the very unusual case of two different providers doing the same proxy aggregation simulatneously in different parts of the world (e.g. 193/8 being created on export to North America, and simultaneously being created by someone else on export to the Middle East). This isn't important for this section of the text (which, as you point out, is about Inetnums). > > * random thought: If a Community guardian file specifies a Route (prefix/ > * length) that is registered more than once, I guess that all instances of > * that Route are marked with the community name? > > Again, as I will explain in more detail tomorrow (I'll first try and > fix the text in the actual document up a bit to make it clearer) there > will never be guardian files anymore with the new stuff. Maintainer > and notification will handle it all. In the RIPE meeting, people could > live with the fact that communities will not be as strictly guarded as > they were, but will merely be "notified". Current community guardians > thought this was good enough. And, with the introduction of netlists > in policy expressions, you will need much less communities than > before. Ouch! You aren't going to want to see my netlists embedded within policy expressions if they are 40,000 nets long. But I'll look forward to your elaborations about communities. Thanks for the extensive reply! :-) > > * Nice paper; nice design. > > Thank you! > > -Marten > --Dale -------- Logged at Thu Sep 15 12:31:29 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Sep 15 12:31:26 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 15 Sep 1994 12:31:26 +0200 Subject: Transition Draft Comments In-Reply-To: Your message of Wed, 14 Sep 1994 17:07:34 EDT. <199409142107.RAA23931@merit.edu> Message-ID: <9409151031.AA19694@reif.ripe.net> > "Dale S. Johnson" writes: > ... > > I wonder if we have a fundamental nomenclature problem, though, about > what a route is? I'm used to thinking of a route as the combination of > the dotted-quad and the mask, so that "193.0.0.0/8" and "193.0.0.0/24" > are different routes. Under this definition, you would still only have > one active registration of a route at one time, except for the very > unusual case of two different providers doing the same proxy aggregation > simulatneously in different parts of the world (e.g. 193/8 being created > on export to North America, and simultaneously being created by someone > else on export to the Middle East). A route is uniquely identified by the "route" and "origin" attributes. route: 193.0.0.0/24 descr: RIPE-NCC origin: AS3333 .... and route: 193.0.0.0/24 descr: RIPE-NCC origin: AS4444 .... are different routes. Daniel -------- Logged at Fri Sep 16 15:36:13 MET DST 1994 --------- From rlr at merit.edu Fri Sep 16 15:35:54 1994 From: rlr at merit.edu (Rick Riolo) Date: Fri, 16 Sep 1994 09:35:54 -0400 Subject: Transition Draft Comments & Communities In-Reply-To: Your message of "Wed, 14 Sep 1994 17:07:34 EDT." <199409142107.RAA23931@merit.edu> Message-ID: <199409161335.JAA13658@toad.merit.edu> Marten, maybe I anticipate your comments on communities...but how about this suggestion for them: implement them like as-macros, ie, the list of routes in the comm stored in some repeating attribute? the new authorization stuff can take care of that part of the problem. (of course for the PRDB this still leaves some big objects in the db, ie, communities with lots of nets. but at least its isolated to those objects, and not spread over a zillion files, and of course is public.) - r -------- > From: "Dale S. Johnson" > To: Marten.Terpstra at ripe.net > CC: rr-impl at ripe.net > Marten, > > I didn't copy the list on my message because I thought most of my > comments were superficial. But your answers weren't superficial, so > I've added the list. > > --------------------------------------------------------------------------- > > From marten at ripe.net Wed Sep 14 15:53:07 1994 > > To: "Dale S. Johnson" > > Cc: Tony.Bates at ripe.net, daniel at ripe.net > > Subject: Re: Transition Draft Comments > > From: Marten Terpstra > > > > ...tons of stuff deleted... -------- Logged at Fri Sep 16 15:52:04 MET DST 1994 --------- From Tony.Bates at ripe.net Fri Sep 16 15:51:59 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Fri, 16 Sep 1994 15:51:59 +0200 Subject: Document update Message-ID: <9409161352.AA12637@mature.ripe.net> As agreed at the last RIPE meeting, we have made updates to the following documents and moved them to final draft to be released as RIPE documents on the 30th September. They are as follows RIPE-81++ --------- ftp://ftp.ripe.net/ripe/drafts/ripe-81++.{ps,txt} Classless Representation ------------------------ ftp://ftp.ripe.net/ripe/drafts/clarep.{ps,txt} Authorization ------------- ftp://ftp.ripe.net/ripe/drafts/ripe-auth.{ps,txt} Transition Plan --------------- ftp://ftp.ripe.net/ripe/drafts/db-trans.{ps,txt} Inet-rtr object ---------------- ftp://ftp.ripe.net/ripe/drafts/inet-rtr.{ps,txt} Update to inetnum ----------------- ftp://ftp.ripe.net/ripe/drafts/ripe-inetnum.{ps,txt} Also, find the start of the experimental objects and attributes document for ripe-81++ extensions. ftp://ftp.ripe.net/ripe/drafts/experimental.{ps,txt} This is a placeholder for a more involved document to follow. Please make sure all comments are sent within two weeks. This message will also be sent to all AS and Community guardians. Apologies for any duplication but we want to make sure we reach all parties involved. --Tony, Marten and Daniel. -------- Logged at Sat Sep 17 22:02:06 MET DST 1994 --------- From Tony.Bates at ripe.net Sat Sep 17 22:01:38 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Sat, 17 Sep 1994 22:01:38 +0200 Subject: semantics ambiguity with interas-in/out: clarification sought In-Reply-To: Your message of Mon, 12 Sep 1994 11:53:07 PDT. <199409121853.AA05050@chl.isi.edu> Message-ID: <9409172001.AA16081@mature.ripe.net> cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * * as-in: AS1 pref1 polexpr1 * interas-in: AS1 lid rid pref2 polexpr2 * * with the above description, the routes imported through (rid, lid) * connection is: * polexpr1 or polexpr2 * with the following preferences: * pref2 polexpr2 * pref1 (polexpr1 setminus polexpr2) * * Is this right? (If it is, including above more formal formulation * might help more implementors). * Nope 0 there is no relation between the prefs. Also as-in must describe the set of al interas-ins. * Eg. * as-in: AS1 100 AS2 AS3 AS4 * interas-in: AS1 lid rid 90 AS2 AS4 AS5 * * that is import routes in * AS2 AS3 AS4 AS5 * with the following preferences * 90 AS2 AS4 AS5 * 100 AS3 * * Is this right? * See above - there is no relation between the cost in as-in and the pref in interas-in. * More complicated E.g. * as-in: AS1 100 AS2 AS3 AS4 * interas-in: AS1 lid rid 90 (AS2 AS4 AS5) AND NOT AS3 * * Note that "(AS2 AS4 AS5) AND NOT AS3" is equivalent to "AS2 AS4 AS5". * Hence this example is identical to previous one and there is no way to * avoid importing routes in AS3. * * Actually with the current definitions there is no way that the local * policies can be a restricted version (subset) of global * policies. (Unless the global policy is "NOT ANY" and everything is * done through local policies. Of course, this is not intended.) * * Is this right? * Nope as the original assumption is not right. Why not check the text in the light of changes I made in the final draft just released. Hopefully, this is a little clearer than before. --Tony. -------- Logged at Sun Sep 18 18:47:23 MET DST 1994 --------- From dsj at merit.edu Sun Sep 18 18:47:16 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Sun, 18 Sep 1994 12:47:16 -0400 Subject: COMMunities still confusing Dale Message-ID: <199409181647.MAA08924@merit.edu> Marten, Tony, Daniel, I've been working through the final drafts to see if I can figure out how Communities work, but I'm still having problems. Ripe-181 still says (p 27): The community tags can only be created and updated by the "guardian" of the community and not by those directly responsible for the particular network. This ensures that community guardians remain in control of community membership. This still seems to imply some mechanism with the functionality of a guardian file, where the owner of the community decides which Route objects are stamped with the community name. Auth (p 9) says: Note that this rule changes the level of membership control exercised by community and AS guardians have with respect to the "guardian file" method. Control is now by notification after the fact. This implies that anyone entering or modifying a Route object can mark it as belonging to any community he wishes--and that the community owner just gets email afterword. It also sounds to me (without further explanation somewhere) as though someone wanting to create a new community would have to find all of the owners of all of the routes that should belong to that community, and would have to contact them out-of-band with messages saying "I've just created this new community COMM_GOODGUYS, would you mind editing all of the following routes to include COMM_GOODGUYS in their comm-list attribute?". To create the NSFNET community in your example, we would have to make out-of-band requests to the 464 ASs that are currently submit have registered NSFNET routes in the PRDB, asking each of them to modify their entries for us. It would also imply that the Guardians still need to keep a file of who they think *should* be members of their community, though now this file has moved from being a Guardian File hosted on a Routing Registry machine to being something that keep privately for their own use. Am I still misunderstanding? Is there a section of the new drafts that I've missed, or a new document that will explain this that will be out soon? Sorry to be pushy on this; we need to be coding this functionality this week in order to configure the Route Servers, and we're trying as hard as we can to do it within the RIPE-181 framework. If I do have this right, the Community structure seems unusable for storing net lists for use in local configuration generation. The best solution I can see for adding the functionality we need would be the one Rick suggested Friday: add a new object for that purpose which could be used with the experimental DBSELECTOR to come up with specific net lists. This is essentially what Laurent has implemented in alc, except that those lists are in private files that only alc knows about, rather than being part of the Routing Registry that is visible through whois, ftp dumps, etc. Again, assuming I'm not still misunderstanding the new community implementation, does this sound like the most RIPE-181-like implmentation we can come up with for storing local routing info for our 40K registered routes, while still making that information available as part of the registry? Any other ideas? --Dale -------- Logged at Sun Sep 18 20:41:18 MET DST 1994 --------- From Marten.Terpstra at ripe.net Sun Sep 18 20:41:09 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Sun, 18 Sep 1994 20:41:09 +0200 Subject: COMMunities still confusing Dale In-Reply-To: Your message of Sun, 18 Sep 1994 12:47:16 EDT. <199409181647.MAA08924@merit.edu> Message-ID: <9409181841.AA07738@ncc.ripe.net> Hi Dale, * Ripe-181 still says (p 27): * * The community tags can only be created and updated by the "guardian" * of the community and not by those directly responsible for the * particular network. This ensures that community guardians remain * in control of community membership. * * This still seems to imply some mechanism with the functionality of a * guardian file, where the owner of the community decides which Route * objects are stamped with the community name. I think we have overlooked this bit of ripe-81++, it needs to be changed to reflect the bits in the Authorisation paper. * Auth (p 9) says: * * Note that this rule changes the level of membership control * exercised by community and AS guardians have with respect * to the "guardian file" method. Control is now by notification * after the fact. * * This implies that anyone entering or modifying a Route object can * mark it as belonging to any community he wishes--and that the community * owner just gets email afterword. It also sounds to me (without further * explanation somewhere) as though someone wanting to create a new * community would have to find all of the owners of all of the routes * that should belong to that community, and would have to contact them * out-of-band with messages saying "I've just created this new community * COMM_GOODGUYS, would you mind editing all of the following routes to * include COMM_GOODGUYS in their comm-list attribute?". To create the * NSFNET community in your example, we would have to make out-of-band * requests to the 464 ASs that are currently submit have registered * NSFNET routes in the PRDB, asking each of them to modify their * entries Basically yes, they would have to. Or, with the current implementation of the authorisation, just send it in with the correct community, and the proper maintainer will receive the request. I still think that community based policies should be avoided as much as possible, simply because they won't scale, and will provide more surprises than solutions. To me I think you are still thinking of the current NSFnet way of doing things. Personally I do not think there'll be communities with thousands of routes actually being used for routing. It'll be AS based more than anything else. Keeping communities is simply a pain. Add some aggregation, and community based routing is even more of a problem. * for us. It would also imply that the Guardians still need to keep a * file of who they think *should* be members of their community, though * now this file has moved from being a Guardian File hosted on a Routing * Registry machine to being something that keep privately for their own * use. Yes. * Am I still misunderstanding? Is there a section of the new drafts * that Noop. * I've missed, or a new document that will explain this that will be out * soon? Sorry to be pushy on this; we need to be coding this functionality * this week in order to configure the Route Servers, and we're trying as * hard as we can to do it within the RIPE-181 framework. * * If I do have this right, the Community structure seems unusable for * storing net lists for use in local configuration generation. The best * solution I can see for adding the functionality we need would be the * one Rick suggested Friday: add a new object for that purpose which * could be used with the experimental DBSELECTOR to come up with specific * net lists. This is essentially what Laurent has implemented in alc, * except that those lists are in private files that only alc knows about, * rather than being part of the Routing Registry that is visible through * whois, ftp dumps, etc. Again, assuming I'm not still misunderstanding * the new community implementation, does this sound like the most * RIPE-181-like implmentation we can come up with for storing local * routing info for our 40K registered routes, while still making that * information available as part of the registry? Any other ideas? Well, do you really think you will need communities with 40+ thousand nets? The reason for creating communities is because of different policies for various nets inside an AS. Will this still be necessary in post NSFnet days? I'd like to see communities more as an exception, rather than a rule .... Of course, this is my opinion. Now, ripe-81++ does not (or should not) contain any details on how the ripe-81 style "guarded attributes" are maintained. We think it can be implemented through the Notification scheme, but you may have a different idea. I like Rick's idea, but it;s got a definate scaling problem (if you *really* need 40K+ communities). There's other ways (like "on-the-fly" addition of communities from files) or even more strict ones. We took the "light-weight" approach... -Marten -------- Logged at Mon Sep 19 00:59:22 MET DST 1994 --------- From dsj at merit.edu Mon Sep 19 00:59:18 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Sun, 18 Sep 1994 18:59:18 -0400 Subject: COMMunities still confusing Dale Message-ID: <199409182259.SAA25596@merit.edu> Marten, Thanks for your answers and your patience. I think I am no longer confused. > I still think > that community based policies should be avoided as much as possible, > simply because they won't scale, and will provide more surprises than > solutions. To me I think you are still thinking of the current NSFnet > way of doing things. Personally I do not think there'll be communities > with thousands of routes actually being used for routing. It'll be AS > based more than anything else. Keeping communities is simply a pain. > Add some aggregation, and community based routing is even more of a > problem. Setting up the initial software to do net-based policy is major job. Operating it (e.g. the NACR process) is an ongoing expense as well, and there are additional costs for the additional load that gets imposed on the routers. (Some of the AS690 config files are 5 meg). On the other hand, you get an ability to fine-tune things, to make creative solutions, and to control business situations that you probably don't have with AS policy. Given the cost of building a major commercial network, the extra complexity to be able to control is isn't really a lot. But it is the NSPs/ISPs who will end up making the business case decisions that will eventually decide this. > Well, do you really think you will need communities with 40+ thousand > nets? The reason for creating communities is because of different > policies for various nets inside an AS. Will this still be necessary in > post NSFnet days? I'd like to see communities more as an exception, > rather than a rule .... Of course, this is my opinion. I'm fairly sure that at least two of the ASs at the NAPs will have net-based policies. If even one does, then the NAP Route Servers need to be able to handle that. > Now, ripe-81++ does not (or should not) contain any details on how the > ripe-81 style "guarded attributes" are maintained. We think it can be > implemented through the Notification scheme, but you may have a > different idea. I like Rick's idea, but it;s got a definate scaling > problem (if you *really* need 40K+ communities). There's other > ways (like "on-the-fly" addition of communities from files) or even > more strict ones. We took the "light-weight" approach... I appreciate the flexibility; and the "on-the-fly" approach for whois output could turn out to be quite nice. I do sense a need to document this stuff somewhere; perhaps a paragraph in the authorization paper would do for this round. We'll write a full document or a section of one when we get whatever system we end up building up and running. Thanks again for the answers. I'll get back with a few more minor notes on the texts later. --Dale -------- Logged at Tue Oct 4 15:55:13 MET 1994 ---------