A quick clarification:  delete does work, but the syntax is more delicate.  For example to delete a neighbor you have to terminate the hierarchy with a ";" and exclude the contents "{...}" from the statement.  Of course you are correct that someone would still have to implement it in a toolset, whether home-grown, or otherwise.<br>

<br>For example,<br>protocols {<br>  bgp {<br>    group  PRIVATE-PEER {<br>      delete: neighbor 1.1.1.2;<br>    }<br>  }<br>}<br><br>Works fine from a text standpoint.  If you are using xml, you have to do something like <br>

...<br><neighbor delete="delete"><br>   <name>1.1.1.2</name><br></neighbor><br>...<br><br>
      <br><div class="gmail_quote">On Tue, Mar 6, 2012 at 2:36 PM, Robin Pimentel <span dir="ltr"><<a href="mailto:robin@pimentel.me">robin@pimentel.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I'm sure you and others are aware of workarounds for 1).  One approach to try is to "replace:" at the "group" level of the hierarchy, or more generally: one level up.  Of course, this means one would have to programmatically have a way of populating the correct neighbors on a per-router, per-group basis (or derive it from the existing config), but it is one way.  Unfortunately, it also means you may be developing your own tool set :/ . I for one would like to see Junos implement the "delete:" tag.<br>


<br><div class="gmail_quote"><div><div class="h5">On Mon, Mar 5, 2012 at 12:52 AM, Vladimir Prokofyev <span dir="ltr"><<a href="mailto:themightywisp@gmail.com" target="_blank">themightywisp@gmail.com</a>></span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi.<div><br></div><div>I have some suggestions for JUNOS-style configuration of rtconfig. Would be nice if someone more skilled than me could implement them.</div><div><br></div><div>1. "load set" configuration style.</div>




<div>Current JUNOS configuration is compatible only with "load merge/replace/override" style, which is not very usable. For example, there isn't any "delete" statement before any configuration statement, which means that every time you delete a peer from a list you have to manually control you configuration update, or all policy lists shift numbers, and configuration becomes incorrect.</div>




<div>For example, cisco-style configuration has a "no" statement before any policy-map/prefix-list/etc, ensuring that there won't be any configuration overlaps from old/new peers/configurations.</div><div><br>




</div><div>2. Ability to specify a VR for a peer.</div><div>For example, I have some peers in separate VR, and it would be great to have a config option that specifies VR for a peer.</div><div>If nothing is set - leave default.</div>




<div>Cisco-style would also benefit from this feature.</div><div><br></div><div>3. IPv4/IPv6 prefix lists in separate policies.</div><div>Currently if I have two peers with single BGP-neighbour(same ASN) - one IPv4 and one IPv6 - it creates single prefix-list for them both. This configuration is unable to commit.</div>




<div><br></div><div>Those three are the only things that separate me from peer update automatisation heaven :) or so I think at the moment.</div>
<br></div></div>_______________________________________________<br>
irrtoolset mailing list<br>
<a href="mailto:irrtoolset@lists.isc.org" target="_blank">irrtoolset@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/irrtoolset" target="_blank">https://lists.isc.org/mailman/listinfo/irrtoolset</a><br></blockquote></div><br>
</blockquote></div><br>