From pavlin@icir.org  Wed Mar  1 00:50:37 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 28 Feb 2006 16:50:37 -0800
Subject: [Xorp-hackers] XORT-NAT: Proposal for NAT interface XIF and a config file syntaks
In-Reply-To: Message from Kristen Nielsen <krn@krn.dk>
 of "Mon, 20 Feb 2006 17:58:50 +0100." <43F9F54A.9020909@krn.dk>
Message-ID: <200603010050.k210objj001229@possum.icir.org>

Kristen,

Thank you for your email.
After the 1.2 release we will evaluate carefully your proposal
and will reply to the list.

Pavlin

> This is a multi-part message in MIME format.
> --------------040204020303010209060700
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi XORP Hackers.
> 
> After a long time of considerations and working on specifying a
> configuratoin syntax and a XIF file for a NAT module, I am hereby
> sending this proposal to the list for comments.
> 
> (Re my mail from oct 16 2005 with subject: NAT support for XORP)
> 
> 
> 20060200-NAT-interface-descr.txt file contains the syntax and a few
> samples of use of the configuration format.
> 
> The nat.xif file has kdoc documentation documenting the various
> functions and parameters.
> 
> The idea is to provice a common interface for the NAT module, with a
> defined syntax, and then use either the native (FreeBSD natd/or the
> similar functionality in linux) daemon, or  a click module, with a rule
> of thumb something like this:
> 
> If the nat configuration is possible to implement with the native module
> this can be used, else the user must switch to the click nat module to
> achieve the wanted functionality.
> 
> I have designed with the use of IP-realms (aka different ip domains)
> which I am aware of is not possible to use in the standard ip stack of
> Freebsd/Linux, but if one make configurations with non overlapping ip
> ranges it will actually be possible to implement theese in the existing
> kernel / ip stacks. The realm stuff is kept entirely in the nat config
> area of the config file.
> 
> I would apreaciate comments on this, as I would like to continue
> planning and coding soon.
> 
> I would also like to have ideas / comments about how to add more
> datatypes to the idl generator scripts. (for the port type, and an
> eventually ipv4-range type (which I here has made with 2 ipv4 ip-addresses.)
> 
> 
> Sincerely
> Mr. Kristen Nielsen
> University of Copenhagen
> Copenhagen
> Denmark
> kristen@diku.dk / krn@krn.dk
> phone +4540466221 (gmt -1)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (FreeBSD)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFD+fVJe7tFxipD00wRApbiAJ9p3KmXx/FN7EUjdmMh7hi0szs4hgCgmTNb
> fzLck6xcwnqSfqA3uYgrphA=
> =wZHj
> -----END PGP SIGNATURE-----
> 
> --------------040204020303010209060700
> Content-Type: text/plain;
>  name="20060220-NAT-interface-descr.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="20060220-NAT-interface-descr.txt"
> 
> * Short description of the config file format for the xorp NAT module.
> * Examples of configurations with alike FreeBSD natd commandline.
> * Syntax of the port statement.
> 
> protocols {
>      nat {
> 	disable {disabled:bool}
> 
>   	nat-realm <text:realm-name> <description: description:txt> {
> 
> 		interface <ifname> vif <vif-name>  { 
> 			description <description:txt>
> 			default-vif-address: <vif-hw-name:txt>
> 			ip-address: <ip:ipv4>
> 			tag: <tagid:txt>
> 
> 			interface-alias {
> 			description: <description:txt>
> 				alias-address: <ip:ipv4list> /* alt to more interface-alias clauses */
> 				tag: <tagid:txt>
> 			}
> 		}
> 		
> 		/* Address pool maps to the create/delete/get_nat_realm4 function) */
> 		address-pool {
> 			description: <description:txt>
> 			ip-address: <ip:ipv4>
> 			ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 			ipnet: <ipnet:ipv4net>
> 			tag:  <tag:txt>
> 		}
> 	}
> 
> 	static-nat {
> 		map {
> 			description: <description:txt>
> 			source { 
> 				realm: <srcrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 			destination {
> 				realm: <destrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 		}
> 	}
> 
> 	dynamic-nat {
> 		map {
> 			description: <description:txt>
> 			source { 
> 				realm: <srcrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 			destination {
> 				realm: <destrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 				binding: <binding:txt>
> 
> 			}
> 		}
> 
> 	ls-nat {
> 		map {
> 			description: <description:txt>
> 			source { 
> 				realm: <srcrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 			destination {
> 				realm: <destrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 		}
> 	}
>      }
> }
> 
> 
> The "port:" parameter is used to set the ports in use for an actual translation.
> 
> Syntax:
> 
> <ports-stmt> ::= ports: <port-def>
> <ports-def> ::= <protocol> <port-list>
> <port-list> ::=  <port-spec> [, <port-def>]...
> <port-spec> ::= <port-nr | service-name> | <port-range | service-name-range>
> <protocol> ::= tcp | udp
> <port-nr> ::=  <digits>
> service-name ::= <letters><letters|digits>...
> digits ::= <digit>...
> digit ::= <0|1|2|3|4|5|6|7|8|9>
> letters ::= <letter>...
> letter ::=<a...z|A..Z>
> 
> Example:
> 
> ports: tcp 22,33,44-55, udp 22,33,66-77, 88
> 
> 
> Sample configurations with similar FreeBSD natd mappings.
> 
> The FreeBSD 
> 
> "natd -redirect_port tcp 172.17.16.15/telnet 6666" 
> 
> command with the global ip address equal to 80.10.10.10 is expressed in XORP NAT configuration files as:
> 
> protocols {
> 	NAT {
> 		realm "global" {
> 			ip: 80.10.1010
> 		}
> 		
> 		realm "local" {
> 			ip: 172.17.16.15	
> 		}
> 		static-map { <description> 
> 			source { ip-address: 80.10.10.10
> 				  ports: tcp 6666
> 			}
> 
> 			destination {
> 				ip-address: 172.17.16.15
> 				ports: tcp telnet
> 			}
> 		}
> 	}
> }        
> 
> The configline: 
> "natd -interface em0"
> Creation of a dynamic mapping from 172.17.16/24 to global address of em0 interface = ip 80.10.10.10 is expressed as:
> 
> protocols {
> 	NAT{
> 		realm "global" {
> 			ip: 80.10.10.10
> 			tag "globalip"
> 		}
> 		
> 		realm "local" {
> 			ipnet: 172.17.16.0/24
> 			tag: "localnet"}	
> 
> 		dynamic-map { <description> 
> 			source {tag: "localnet"
> 			}
> 			destination {
> 				tag: "globalip"
> 			}
> 		}
> 	}
> }        
> Written by 
> Kristen Nielsen
> Computer Science dept
> University of Copenhagen, Denmark
> kristen@diku.dk / KrN@KrN.dk
> 
> 
> 
> --------------040204020303010209060700
> Content-Type: text/plain;
>  name="nat.xif"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="nat.xif"
> 
> /* xorp/xrl/interfaces/nat.xif file by KrN@KrN.DK 20060220 */
> /* Suggestion to a nat interface for xorp. */
> 
> 
> /* The following interfaces exists for the xorp nat module */
> 
> 	/**
> 	 * Network address translation (NAT) interface.
> 	 * The NAT module consists of the following configuration elements:
> 	 *
> 	 * set_nat_disable and get_nat_disable:
> 	 * 	sets and returns the status of the nat module
> 	 *
>  	 * nat_realm: 
> 	 *	Manages (creates/deletes/get) realms for use in nat mappings.
> 	 *	Before realms can be used in configurations, they must 
> 	 * 	be created.
> 	 *	
> 	 * nat_realm_vif4:
> 	 *	Manages (creates/delete/lists) vif addresses for nat use 
> 	 * 	in nat mappings.
> 	 *
> 	 * nat_realm_alias4:
> 	 *	Manages (creates/deletes/lists) alias ipv4 addresses for vif 
> 	 * 	interfaces for use in nat mappings.
> 	 *
> 	 * nat_realm4:
> 	 *	Defines ip4 addresses, ip4 networks and ip4 address ranges 
> 	 * 	for use in nat mappings. Addresses are not directly connected 
> 	 * 	to any vif on the xorp router. Addresses are reachable 
> 	 * 	via the realm / vif interface stated. (This will probably be
> 	 *	changed to be the interface pointed out by the next-hop entry
> 	 * 	in the rib.)
> 	 *
> 	 * nat_static_map4: 
> 	 *	Defines static NAT table mappings
> 	 *	From the realm and ip definitions in the nat_realm_* group
> 	 *	Tcp and/or udp port definitions can be defined here.
> 	 *
> 	 * nat_dynamic_map4: 
> 	 *	Defines dynamic NAT table mappings (triggers)
> 	 *	From the definitions in the nat_real_* group
> 	 *	Tcp and/or udp port definitions can be defined here.
> 	 *
> 	 * nat_lsnat_map4: 
> 	 *	Defines Load Sharing NAT mappings
> 	 *	From the definitions in the nat_real_* group
> 	 *	Tcp and/or udp port definitions can be defined here.
> 	 *
> 	 */
> interface nat/0.1 {
> 
> 	/** 
> 	 * set nat disable (and enable) function
> 	 *
> 	 * @param disabled sets the status of the nat module true = disabled, 
> 	 * false = enabled
> 	 * @param disabledstatus returns the status of the module, 
> 	 * true = disabled, false = enabled
> 	 */
> 	set_nat_disable		? disabled:bool -> disabledstatus:bool
> 	
> 	/** 
> 	 * get nat status function
> 	 *
> 	 * @param disabledstatus returns the status of the module, (as the 
> 	 * set_nat_disable function)  true = disabled, false = enabled
> 	 */
> 	get_nat_disable		-> disabledstatus:bool
> 
> 
> 	/** 
> 	 * create_nat_realm - creates a nat realm.
> 	 *
> 	 * @param realm holds the name of the realm to be created. The name 
> 	 * must not exist when the call is made.
> 	 * @param descr is the textual description of the realm.
> 	 */
> 	create_nat_realm	? realm:txt & descr:txt
> 	
> 	/** 
> 	 * delete_nat_realm - deletes a nat realm.
> 	 *
> 	 * @param realm holds the name of the realm to be deleted. The name 
> 	 * must exist when the call is made.
> 	 */
>         delete_nat_realm 	? realm:txt
> 	
> 	/** 
> 	 * get_nat_realm - lists nat realms.
> 	 *
> 	 * @param realm holds the name of the realm to be deleted. 
> 	 * If the parameter is NULL, all existing realms is returned.
> 	 */
>         get_nat_realm	 	? realm:txt -> realms:list 
> 
> 
> 	/** 
> 	 * create_nat_realm_vif4 - creates an entry for the base ipv4 address 
> 	 * of a virtual interface. 
> 	 * Any virtual interface can at most be a member of one realm. 
> 	 * Virtual interfaces must be in the same realm as the ip addresses
> 	 * passing the vif interface.
> 	 * 
> 	 * @param realm is an existing realm that the vif is mapped to.
> 	 * @param ifname is the name of the physical interface where the 
> 	 * vif is defined.
> 	 * @param vifname is the name of the virtual interface to be mapped.
> 	 * @param tag is a textlabel that the mapping is labeled with.
> 	 * @param description textual description of the mapping.
> 	 */
> 	create_nat_realm_vif4 	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt & description:txt 
> 
> 	/** 
> 	 * delete_nat_realm_vif4 - removes an entry for a base ipv4 (vif) 
> 	 * address of virtual interface from a nat realm.
> 	 * The definitions matching all the supplied parameters is deleted.
> 	 * Wild card parameters must be set to NULL.
> 	 *
> 	 * @param realm all vif4 definitions to this realm is deleted.
> 	 * @param ifname all definitions with this ifname is deleted. 
> 	 * @param vifname all mappings to this vifname is deleted
> 	 * @param tag all mappings with this tag is deleted.
> 	 */
> 	delete_nat_realm_vif4	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt
> 
> 	/**
> 	 * update_nat_realm_vif4 - updates an existing vif mapping with its
> 	 * new ipv4 address. 
> 	 * The vif4 mapping is updated when the vif get a new ipv4 address.
> 	 */
> 	update_nat_realm_vif4 	? ifname:txt & vifname:txt & ip:ipv4
> 	 
> 	/** 
> 	 * get_nat_realm_vif4 - lists nat_realm_vif4 definitions.
> 	 *
> 	 * get_nat_realm_vif4 returns a list of all nat_realm_vif4 
> 	 * interfaces in the router matching the realm supplied. 
> 	 * @param realm specifies the realm to return interfaces for. 
> 	 * If NULL then all defined nat_realm_vif4 interfaces are returned.
> 	 */
> 	get_nat_realm_vif4 	? realm:txt -> nat_realm_vif4s:list
> 
> 	
> 	/** 
> 	 * create_nat_realm_alias4 - creates a mapping to the nat_realm 
> 	 * definitions. Manipulates ipv4 address aliases of an interface 
> 	 * (vif) for in/out going nat gateways. Aliases are not the base 
> 	 * ipv4 address of the virtual interface, but ipv4 addresses in 
> 	 * the same subnet as the vif. (see nat_realm_vif)
> 	 *
> 	 * Any aliases, aliased to a vif must be in the same realm as the 
> 	 * vif itself.
> 	 *
> 	 * @param realm specifies the realm that the IP address belongs to.
> 	 * @param ifname is the physical interfaces for this interface
> 	 * @param vifname is the virtual interface name to add this alias to.
> 	 * @param tag is a label for grouping definitions.
> 	 * @param description is a textual description of this alias.
> 	 * @param ipaddr is the ipv4 alias address added to the vif.
> 	 */
> 	create_nat_realm_alias4	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt & description:txt & ipaddr:ipv4
> 
> 
> 	/** 
> 	 * delete_realm_alias4 function
> 	 * Deletes ipv4 realm_alias4 address from the virtuel interface (vif). 
> 	 *
> 	 * The alias4 mappings matching the supplied parameters are deleted.
> 	 * Parameters that are not defined (=not matched against) must be NULL. 
> 	 *
> 	 * @param realm the alias4 mappings in the same realm is deleted.
> 	 * @param ifname all alias4 mappings defined for this interface is
> 	 * deleted.
> 	 * @param vifname all alias4 mappings defined under this vif is 
> 	 * deleted.
> 	 * @param tag all alias4 mappings with tag is deleted.
> 	 * @param ipaddr the alias4 mapping with this ipv4 address is deleted.
> 	 */
> 	delete_nat_realm_alias4	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt & ipaddr:ipv4
> 
> 	/**
> 	 * get_nat_realm_alias4 returns a nat_realm_alias4 list with matching 
> 	 * alias4 elements. Wildcard parameters shuld be set to NULL.
> 	 *
> 	 * @param realm specifies the realm of the alias4 addresses to be 
> 	 * returned.
> 	 * @param ifname specifies the physical interfaces to match.
> 	 * @param vifname specifies the virtual interfaces to match.
> 	 * @param tag specifies the tag of the definitions to match.
> 	 * @param ipaddr specifies the ipv4 addr of the alias4 to match.
> 	 * @param nat_realm_alias4s is the list of the matching aliases 
> 	 * defined.
> 	 */
> 	get_nat_realm_alias4	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt & ipaddr:ipv4 \
> 				-> nat_realm_alias4s:list
> 
> 	/** 
> 	 * create_nat_realm - create definitions of ipv4 addresses/ipv4/
> 	 * networks/ipv4 ip ranges to the nat_realm list.
> 	 *
> 	 * The ipv4 addresses / ipv4 networks / ipv4 address ranges / tagged
> 	 * list of definitions, are all ip-addresses not directly attached
> 	 * to any physical/virtual interface on the xorp router.
> 	 * 
> 	 * The function have the following way of interpreting the address 
> 	 * arguments:
> 	 * All function calls must have theese parameters defined: 
> 	 * <realm> <ifname> <vifname>, where realm specifies the actural realm.
> 	 * ifname and vifname the interfaces to route these addresses through.
> 	 * (If the ifname and vifname is possible to acquire via the routing
> 	 * info, these parameters might disappear during implementation) 
> 	 *
> 	 * To specify a tag for the definition, supply the <tag> parameter.
> 	 *
> 	 * To specify an single ipv4 address supply ONLY the <ip> parameter. 
> 	 *
> 	 * To specify an ipv4 network supply ONLY the <ipnet> parameter. 
> 	 *
> 	 * To specify an ipv4 range supply ONLY the <ip> and <ipto> parameters. 
> 	 * <ip> is the lowest ip address and ipto is the highest ip address
> 	 * in the range.
> 	 * 
> 	 * The 3 types of definitions above can not be mixed in a single call
> 	 * to the function. Grouping is done with defining more of the 3
> 	 * first classes with the same tag.
> 	 * 
> 	 * create_nat_realm4 create an ipv4 address/ipv4network/ipv4-range/tag
> 	 * at the nat map list.
> 	 *
> 	 * @param realm specifies the realm to which the mapping belong.
> 	 * @param tag maps the definition with this tag.
> 	 * @param description a textual description of this alias.
> 	 * @param ip is the ip address or the lowest bound of an ip range.
> 	 * @param ipto is the highest bound of a range.
> 	 * @param ipnet specifies an ipv4 network (ip address + subnetmask)
> 	 */
> 	create_nat_realm4	 	? realm:txt & \
> 					tag:txt & description:txt & \
> 					ip:ipv4 & ipto:ipv4 & \
> 					ipnet:ipv4net
> 
> 	/**
> 	 * delete_nat_realm4 deletes all nat_realm4 mappings, matching
> 	 * all supplied parameters. Wild card parameters must be set to NULL.
> 	 * (For further doc see add_nat_realm4)
> 	 *
> 	 * @param realm all nat_realm4 with this realm is deleted.
> 	 * @param tag all nat_realm4 definitions with this tag is deleted.
> 	 * @param ip the ipv4 address mapping is deleted. (see ipto param too)
> 	 * @param ipto the range defined together with the ip parameter is 
> 	 * deleted.
> 	 * @param ipnet the ipv4network defined is deleted.
> 	 * 
> 	 * If more parameters are defined, only the definitions that match 
> 	 * ALL the supplied parameters is deleted. 
> 	 */
> 	delete_nat_realm4 		? realm:txt & \
> 					tag:txt & \
> 					ip:ipv4 & ipto:ipv4 & \
> 					ipnet:ipv4net
> 
> 	/**
> 	 * get_nat_realm4 function - returns the list of defined elements 
> 	 * that matches the supplied parameters.
> 	 * (For further doc on the use see add_nat_realm4 the doc.)
> 	 * Wildcard parameters must be set to NULL.
> 	 *
> 	 * @param realm returns the list of realm4 definitions for this realm.
> 	 * @param tag returns the list of definitions tagged with this tag.
> 	 * @param ip returns the list of definitions with this ipv4 address.
> 	 * @param ipto returns the list of definitions with this ipv4 range. 
> 	 * @param ipnet returns the list of ipv4 networks defined.
> 	 * @param nat_realm4s is a list of the matched definitions.
> 	 */
> 	get_nat_realm4 			? realm:txt & \
> 					tag:txt & description:txt & \
> 					ip:ipv4 & ipto:ipv4 & \
> 					ipnet:ipv4net -> nat_realm4s:list
> 
> 	/**
> 	 * create_nat_static_map4
> 	 *
> 	 * create_nat_static_map4 - defines static NAT table entries from the 
> 	 * ip definitions from the nat_realm* functions.
> 	 *
> 	 * The nat_static_map functions defines static nat mappings between 
> 	 * ip addresses at the source side realm and the ip addresses of 
> 	 * the destination side realm.
> 	 * If the ip sizes of the ranges on either side of the mapping is not 
> 	 * equal, then the mappings must go from the source side realm 
> 	 * (aka local realm) to the destination side realm (aka global realm).
> 	 * ip addresses that is used for TCP/UDP port mapping 
> 	 * (port overloading) must always be defined at the destination side.
> 	 *
> 	 * The nat_static_map function has more sub functions dependent of 
> 	 * the supplied parameters. The parameters can define either a single
> 	 * ip address, a contiguous range of ip addresses or a sub net, or a
> 	 * tagged set of definitions. The ip addresses and realm used in a map 
> 	 * statement must be defined in a nat_realm* clause.
> 	 * The source and destination side of a mapping can take all 4 forms
> 	 * from the following definitions.
> 	 *  
> 	 * To specify a single ip address the ip parameter is used. The 
> 	 * ipto paramter must be NULL.
> 	 * 
> 	 * To specify a contiguous range of IP addresses, the ip and ipto 
> 	 * parameters are used. The ipnet parameter must be NULL.
> 	 * 
> 	 * To specify an ipnetwork, the ipnet parameters must be specified. 
> 	 * The ipnet takes a subnet-address and a submet-mask. The ip and ipto
> 	 * parameters must be NULL.
> 	 * 
> 	 * To use a tag from the nat_realm definitions, specify the tag at 
> 	 * the tag parameter. The ip, ipto and ipnet parameters must be NULL.
> 	 *
> 	 * @param srcrealm specifies the realm for the source side of the map.
> 	 *
> 	 * @param destrealm specifies the realm for the destination side 
> 	 * of the map.
> 	 *
> 	 * @param srcip is the ipv4 source ip address of a mapping.
> 	 *
> 	 * @param srcipto is the source ipv4 address that forms the upper 
> 	 * bound of an ip range.
> 	 *
> 	 * @param srcipnet is the ipv4 network which forms the source mapping.
> 	 * bound of an ip range.
> 	 *
> 	 * @param srctag maps all nat_realm definitions with the same tag as
> 	 * the source definition.
> 	 *
> 	 * @param srcport is the range of ports used to this mapping.
> 	 *
> 	 * @param destip is the ipv4 destination address of the mapping
> 	 *
> 	 * @param destipto is the ipv4 address that forms the upper bound of 
> 	 * the destination ip range. 
> 	 *
> 	 * @param destipnet is the ipv4 network that is the destination ip 
> 	 * addresses for the mapping.
> 	 *
> 	 * @param desttag maps all nat_realm definitions with the same tag as
> 	 * the destination definition.
>  	 *
> 	 * @param destport is a list of tcp and/or udp ports used at the
> 	 * destination addresses.
> 	 *
> 	 */
> 	create_nat_static_map4		? description:txt & \
> 					srcrealm:txt & \
> 					srcip:ipv4 & srcipto:ipv4 & \
> 					srcipnet:ipv4net & \
> 					srctag:txt & \
> 					srcport:ipv4ports & \
> 					destrealm:txt & \
> 					destip:ipv4 & destipto:ipv4 & \
> 					destipnet:ipv4net & \
> 					desttag:txt & \
> 					destport:ipv4ports
> 
> 	/**
> 	 * delete_nat_static_map4
> 	 *
> 	 * delete_nat_static_map4 - delete static nat table entries from the 
> 	 * ip definitions from the nat_static_map4 functions.
> 	 *
> 	 * The function deletes the nat_static_map4 entries that matches
> 	 * all the supplied parameters.  (for more information about the 
> 	 * interfaces see create_nat_static_map4 documentation)
> 	 *
> 	 * The selected ranges must be fully matching sets from the
> 	 * create_nat_static_map4 definition. No internal ranges can be deleted.
> 	 *
> 	 * @param srcrealm specifies the source realm to be deleted. All 
> 	 * nat_static_map4 definitions with the same realm is selected.
> 	 *
> 	 * @param destrealm specifies the realm for the destination side 
> 	 * to be deleted. All nat_static_map4 definitions with the same realm 
> 	 * is selected.
> 	 *
> 	 * @param srcip is the ipv4 source ip address to be deleted.
> 	 *
> 	 * @param srcipto is together with the srcip parameter defines the
> 	 * source ip range to be deleted. 
> 	 *
> 	 * @param srcipnet is the ipv4 network source mapping to be deleted.
> 	 *
> 	 * @param srctag maps selects the source tags to be deleted.
> 	 * 
> 	 * @param srcport is the range of tcp and/or udp ports to be deleted.
> 	 *
> 	 * @param destip is the ipv4 destination address to be deleted.
> 	 *
> 	 * @param destipto is together with the destip parameter defines 
> 	 * the destination ip range to be deleted.
> 	 *
> 	 * @param destipnet is the ipv4 network to be deleted.
> 	 *
> 	 * @param desttag maps defines the destination tags to be deleted.
> 	 *
> 	 * @param destport is a list of tcp and/or udp ports to be deleted.
> 	 */
> 	delete_nat_static_map4		? srcrealm:txt & \
> 					srcip:ipv4 & srcipto:ipv4 & \
> 					srcipnet:ipv4net & \
> 					srctag:txt & \
> 					srcport:ipv4ports & \
> 					destrealm:txt & \
> 					destip:ipv4 & destipto:ipv4 & \
> 					destipnet:ipv4net & \
> 					desttag:txt & \
> 					destport:ipv4ports
> 
> 	/**
> 	 * get_nat_static_map4 - lists nat_static_map4 entries.
> 	 *
> 	 * get_nat_static_map4 - lists static NAT table entries that matches 
> 	 * the supplied parameters.
> 	 *
> 	 * The function deletes the nat_static_map4 entries that is matches
> 	 * all the supplied parameters.
> 	 * (for more information about the interfaces see 
> 	 * create_nat_static_map4 documentation)
> 	 *
> 	 * @param srcrealm specifies the source realm to be listed.
> 	 *
> 	 * @param destrealm specifies the realm for the destination side 
> 	 * to be listed.
> 	 *
> 	 * @param srcip is the ipv4 source ip address to be listed.
> 	 *
> 	 * @param srcipto is together with the srcip parameter defines the
> 	 * source ip range to be listed. 
> 	 *
> 	 * @param srcipnet is the ipv4 network source to be listed.
> 	 *
> 	 * @param srctag maps selects the srctags to be listed.
> 	 *
> 	 * @param srcport is the range of tcp and/or udp ports to be delted.
> 	 *
> 	 * @param destip is the ipv4 destination address to be listed.
> 	 *
> 	 * @param destipto is together with the destip parameter defines 
> 	 * the destination ip range to be listed.
> 	 *
> 	 * @param destipnet is the ipv4 network to be listed.
> 	 *
> 	 * @param desttag maps defines the destination tags to be listed.
> 	 *
> 	 * @param nat_static_map4s contains the list of matched elements.
> 	 *
> 	 * @param destport is a list of tcp and/or udp ports to be matched.
> 	 */
> 	get_nat_static_map4	? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				destport:ipv4ports & \
> 				desttag:txt -> nat_static_map4s:list
> 
> 
> 	/** 
> 	 * create_nat_dynamic map definitions.
> 	 *
> 	 * The nat_static_map functions defines static mappings between 
> 	 * IP addresses at the source side realm and the IP addresses of 
> 	 * the destination side realm.
> 	 * If the IP sizes of the ranges on either side is not equal, 
> 	 * then the mappings must go from the source side realm 
> 	 * (aka local realm) and the destination side realm (aka global realm).
> 	 * IP addresses that is used for TCP/UDP port mapping 
> 	 * (port overloading) must be defined on the destination side.
> 	 *
> 	 * @param srcrealm specify the network realm for the source part
> 	 * of the mapping.
> 	 *
> 	 * @param srctag maps the nat_realm* definitions with this tag as
> 	 * the source side of the mapping. The tagged definitions must belong
> 	 * to the same realm as stated in srcrealm. If the special meaning
> 	 * tag "all" is given then all the definitions in the nat_realm 
> 	 * with the same realm as stated in srcrealm is matched.
> 	 *
> 	 * Src or dest definitions defults to "all" which is all addresses 
> 	 * in the matching (src/dest) realm as defined in nat_realm_* group.
> 	 *
> 	 * @param srcip is the ipv4 source ip address of a mapping.
> 	 *
> 	 * @param srcipnet is the ipv4 network which forms the source mapping.
> 	 *
> 	 * @param scrip is the source ipv4 address that forms the lower bound 
> 	 * of an ip range.
> 	 *
> 	 * @param srcipto is the source ipv4 address that forms the upper 
> 	 * bound of an ip range.
> 	 *
> 	 * @param srcport is the range of tcp and/or udp ports to be used in
> 	 * the mapping.
> 	 *
> 	 * @param destip is the ipv4 destination address of the mapping
> 	 *
> 	 * @param destipnet is the ipv4 network that is the destination ip 
> 	 * addresses for the mapping.
> 	 *
> 	 * @param destip is the ipv4 address that forms the lower bound of the 
> 	 * destination ip range.
> 	 *
> 	 * @param destipto is the ipv4 address that forms the upper bound of 
> 	 * the destination ip range. 
> 	 *
> 	 * @param desttag maps the nat_realm* definitions with this tag as
> 	 * the destination side of the mapping. The tagged definitions must 
> 	 * belong to the same realm as stated in srcrealm. If the special 
> 	 * meaning tag "all" is given then all the definitions in the nat_realm 
> 	 * with the same realm as stated in srcrealm is matched.
> 	 * 
> 	 * @param destport is a list of tcp and/or udp ports to use for the
> 	 * dynamic mapping.
> 	 *
> 	 * @param binding This argument can be "dynamic" (default) or "fixed"
> 	 * Dynamic can be a new mapping each time the mapping is used for a 
> 	 * new connection (from src side). "fixed" is using the same source 
> 	 * and destination mapping each time the src ip/port is connecting.
> 	 */
> 	create_nat_dynamic_map4	? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				binding:txt
> 
> 	/** 
> 	 * delete_nat_dynamic_map4
> 	 * 
> 	 * The delete_nat_dynamic_map4 function deletes the elements from the
> 	 * nat_dynamic_map4 table that matches the supplied parameters.
> 	 *
> 	 * @param srcrealm matches source realm parameter of mappings.
> 	 *
> 	 * @param srctag matches the source tag paramter of the mappings to 
> 	 * be deleted.
> 	 * If the special meaning tag "all" is given then all the definitions 
> 	 * with this tag on the source side is matched. With the same realm 
> 	 * as stated in srcrealm is matched.
> 	 *
> 	 * @param srcip matches the ipv4 source ip, or the lower bound of an
> 	 * ipv4 ip-range to be deleted.
> 	 *
> 	 * @param srcipto matches the source ipv4 address that forms the upper 
> 	 * bound of an ip range to be deleted.
> 	 *
> 	 * @param srcipnet matches the source ipv4 network to be deleted.
> 	 * 
> 	 * @param srcport is the tcp and/or udp port range to be deleted.
> 	 *
> 	 * @param destip matches the ipv4 destination address of the mapping
> 	 * or the ipv4 address that forms the lower bound of the destination
> 	 * ip range.
> 	 *
> 	 * @param destipto matches the destination ipv4 address to be deleted.
> 	 *
> 	 * @param destipnet matches the destination ipv4 network.
> 	 *
> 	 * @param desttag maps the mappings with this tag as the destination 
> 	 * side of the mapping. The tagged definitions must belong to the
> 	 * same realm as stated in srcrealm. If the special 
> 	 * meaning tag "all" is given then all the definitions in the 
> 	 * nat_dynamic_realm with the same source realm as stated in srcrealm 
> 	 * is matched.
> 	 * 
> 	 * @param destport is a list of tcp and/or udp ports to be deleted.
> 	 *
> 	 * @param binding This argument can be "dynamic" (default) or "fixed"
> 	 * Dynamic can be a new mapping each time the mapping is used for a 
> 	 * new connection (from src side). "fixed" is using the same source 
> 	 * and destination mapping each time the src ip/port is connecting.
> 	 */
> 	delete_nat_dynamic_map4	? srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				binding:txt
> 
> 	/** 
> 	 * get_nat_dynamic_map4
> 	 * 
> 	 * The get_nat_dynamic_map4 function returns the elements from the
> 	 * nat_dynamic_map4 table that matches all the supplied parameters.
> 	 *
> 	 * @param srcrealm matches source realm parameter of the mappings.
> 	 *
> 	 * @param srctag matches the source tag parameter of the mappings.
> 	 * If the special meaning tag "all" is given then all the definitions 
> 	 * with this tag on the source side is matched. With the same realm 
> 	 * as stated in srcrealm is matched.
> 	 *
> 	 * @param srcip matches the ipv4 source ip, or the lower bound of an
> 	 * ipv4 ip-range.
> 	 *
> 	 * @param srcipto matches the source ipv4 address that forms the upper 
> 	 * bound of an ip range.
> 	 *
> 	 * @param srcipnet matches the source ipv4 network.
> 	 * 
> 	 * @param srcport is the tcp and/or udp range to be returned.
> 	 *
> 	 * @param destip matches the ipv4 destination address of the mapping
> 	 * or the ipv4 address that forms the lower bound of the destination
> 	 * ip range.
> 	 *
> 	 * @param destipto matches the destination ipv4 address.
> 	 *
> 	 * @param destipnet matches the destination ipv4 network.
> 	 *
> 	 * @param desttag maps the mappings with this tag as the destination 
> 	 * side of the mapping. The tagged definitions must belong to the
> 	 * same realm as stated in srcrealm. If the special 
> 	 * mening tag "all" is given then all the definitions in the 
> 	 * nat_dynamic_realm with the same source realm as stated in srcrealm 
> 	 * is matched.
> 	 *
> 	 * @param destport is a list of tcp and/or udp ports to be returned.
> 	 *
> 	 * @param binding This argument can be "dynamic" (default) or "fixed"
> 	 * Dynamic can be a new mapping each time the mapping is used for a 
> 	 * new connection (from src side). "fixed" is using the same source 
> 	 * and destination mapping each time the src ip/port is connecting.
> 	 */
> 	get_nat_dynamic_map4	? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				binding:txt -> nat_dynamic_map4s:list
> 
> 
> 
> 	/** 
> 	 * lsnat_map functions - define Load Sharing NAT (LSNAT) functionality.
> 	 *  
> 	 * lsnat_map defines hosts at the destination side which is to be
> 	 * loadshared when accesses via a common global address and port, 
> 	 * defined at the source side.
> 	 *
> 	 * The lsnat_map function has a range of ways to define ipv4 addresses,
> 	 * ipv4 networks and ipv4 ip address ranges.
> 	 * The parameters can define either a single ip address, a contigous 
> 	 * range of IP addresses or a subnet, or a tag.
> 	 * The source and destination side of a mapping can each take all 
> 	 * 4 forms.
> 	 *  
> 	 * To specify an single ip address the ip parameter is used. The 
> 	 * ipto paramter must be NULL.
> 	 * 
> 	 * To specify a contiguous range of IP addresses, the ip and ipto 
> 	 * parameters are used. The ipnet parameter must be NULL.
> 	 * 
> 	 * To specify an ipnetwork, the ipnet parameters must be specified. 
> 	 * The ipnet takes a sub net-address and a sub net-mask. The ip and ipto
> 	 * parameters must be NULL.
> 	 * 
> 	 * To use a named tag from the nat_realm definitions, specify the tag 
> 	 * at the tag parameter. The ip, ipto and ipnet parameters must be 
> 	 * NULL. Tags with the special value "all" matches all defined 
> 	 * addresses in the same realm as the tag.
> 	 *
> 	 * @param srcrealm defines which realm the source addresses belongs 
> 	 * to. The common ip addresses to access the load shared services must
> 	 * be load shared must be connected to the source side of the map. 
> 	 *
> 	 * @param destrealm defines which realm the destination addresses  
> 	 * belongs to (host network realm). The ip addresses of the hosts
> 	 * with the services to be load shared is on this realm.
> 	 *
> 	 * @param srcip is the ipv4 source ip address of a mapping.
> 	 *
> 	 * @param srcipto is the source ipv4 address that forms the upper 
> 	 * bound of an ip range.
> 	 *
> 	 * @param srcipnet is the ipv4 network which forms the source mapping.
> 	 * bound of an ip range.
> 	 *
> 	 * @param srctag maps all nat_realm definitions with the same tag as
> 	 * the source definition. The special tag value "all" matches all 
> 	 * definitions from the nat_realm with the same realm.
> 	 *
> 	 * @param srcport is the list of tcp and/or udp ports to created.
> 	 *
> 	 * @param destip is the ipv4 destination address of the mapping
> 	 *
> 	 * @param destipto is the ipv4 address that forms the upper bound of 
> 	 * the destination ip range. 
> 	 *
> 	 * @param destipnet is the ipv4 network that is the destination ip 
> 	 * addresses for the mapping.
> 	 *
> 	 * @param desttag maps all nat_realm definitions with the same tag as
> 	 * the destination definition. The special tag value "all" matches all 
> 	 * definitions from the nat_realm with the same realm.
> 	 *
> 	 * @param destport is the tcp and/or udp port to load share.
> 	 *
> 	 * @param lsalgorithm defines the load sharing algorithm, and takes 
> 	 * the values: round-robin, random, (more ?), ...
> 	 *
> 	 */
> 
> 	/**
> 	 * create_lsnat_map4 function -
> 	 * Creates a lsnat_map4 table entry to the nat mappings.
> 	 */
> 	create_lsnat_map4	? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				lsalgorithm:txt
> 
> 	/**
> 	 * delete_lsnat_map4 function -
> 	 * Deletes the lsnat_map4 tableentries from the nat mappings that
> 	 * matches all the defined parameters.
> 	 */
> 	delete_lsnat_map4	? srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 
> 	/**
> 	 * get_lsnat_map4 function -
> 	 * Lists lsnat_map4 table entries that matches all the defined the
> 	 * parameters. 
> 	 */
> 	get_lsnat_map4		? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				lsalgorithm:txt -> lsnat_map4s:list
> }
> 
> 
> 
> --------------040204020303010209060700--
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From johan@capvert.se  Fri Mar  3 13:23:32 2006
From: johan@capvert.se (johan@capvert.se)
Date: Fri, 3 Mar 2006 14:23:32 +0100
Subject: [Xorp-hackers] dist/kernel
Message-ID: <OF47B996CB.865A96B8-ONC1257126.00495877@capvert.ins>

                                               Hi!


I´m not a subscriber yet, but I tried to find out what distribution/kernel
you´re using, or if you got your own build?

               Best regards from/Med vänliga hälsningar från

                                 Johan Kragsterman

                               http://www.capvert.se



From kristian@juniks.net  Tue Mar  7 21:51:49 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Tue, 7 Mar 2006 22:51:49 +0100
Subject: [Xorp-hackers] dist/kernel
In-Reply-To: <OF47B996CB.865A96B8-ONC1257126.00495877@capvert.ins>
References: <OF47B996CB.865A96B8-ONC1257126.00495877@capvert.ins>
Message-ID: <20060307215148.GD7965@juniks.net>

On Fri, Mar 03, 2006 at 02:23:32PM +0100, johan@capvert.se wrote:
>                                                Hi!
> 
> 
> I?m not a subscriber yet, but I tried to find out what distribution/kernel
> you?re using, or if you got your own build?
XORP isn't kernel/distribution specific in any
way. It's being developed on a mixture of
platforms such as FreeBSD and Linux.

XORP is regularly compiled on a tinderbox to make
sure it compiles on the supported platforms.

The LiveCD is based on FreeBSD (last time I
checked). 

You could also check out the Vyatta project which
is a complete router on a CD based on XORP and
other open source software.
> 
>                Best regards from/Med vänliga hälsningar från
> 
>                                  Johan Kragsterman
Hälsningar,
Kristian

From kristian@juniks.net  Wed Mar  8 13:38:27 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Wed, 8 Mar 2006 14:38:27 +0100
Subject: Ang: Re: [Xorp-hackers] dist/kernel
In-Reply-To: <OF860D18C7.C15D93AF-ONC125712B.0031DAEA@capvert.ins>
References: <OF860D18C7.C15D93AF-ONC125712B.0031DAEA@capvert.ins>
Message-ID: <20060308133827.GI24723@juniks.net>

On Wed, Mar 08, 2006 at 10:28:50AM +0100, johan@capvert.se wrote:
> 
>                                   Hej, Kristian!
> 
> 
>  Thanks for your answer! Are you by any chance Swedish? Your name suggests
> that.
Indeed, I am :)
> Anyway, we?re running a project called ior, which is a multiprotocol
> storage router. We?ve been doing this for a while now, and the project is
> registred on SF.net, but so far we haven?t released any files. Why we look
> at xorp because we are evaluating different RTOS alternatives. Maybe it
> would be nice with not only OS, but also a complete router platform. We
> will use protocols like fc and iscsi(which also of coarse means tcp/udp)
> primarily, mabe later something like fcip, ifcp and infiniband. What can
> you say about xorp?s RT features? Other comments you got for us?
Well, as I've mentioned in my previous mail, xorp
is independant from the operating system it's run
on. Generally I don't think you can make any
realtime guarantees when system becomes as
complex as XORP and it's underlying operating
system. On top of that, there are some issues with
the speed of XORP right now. Using XORP for
"regular" routing it can be very slow compared to
other routing suites, such as Quagga. Though this
is something I am certain will be resolved in the
not so distant future.
Take notice that the speed of XORP merely affects
routing changes, ie topology changes. Any
forwarding of packets are handled by the
underlying operating systems and it would thus be
up to it to provide realtime support.
There are some "realtime" patches for Linux which
you could check out.

I am not very educated on the finer workings of FC
or iSCSI and therefore cannot judge how advanced
any routing protocols for it would be. What I do
know is that XORP provides a vial option for
developing new protocols. It's framework let you
save quite some development time although it is 
aimed at more regular ip routing protocols such 
as OSPF and BGP.


Regards,
   Kristian



> 
>                Best regards from/Med vänliga hälsningar från
> 
>                                  Johan Kragsterman
> 
>                                http://www.capvert.se
> 
> 
>                                                                                                                     
>                     Kristian                                                                                        
>                     Larsson              Till:   johan@capvert.se                                                   
>                     <kristian@juni       Kopia:  xorp-hackers@xorp.org                                              
>                     ks.net>              Ärende: Re: [Xorp-hackers] dist/kernel                                     
>                                                                                                                     
>                     2006-03-07                                                                                      
>                     22:51                                                                                           
>                                                                                                                     
>                                                                                                                     
> 
> 
> 
> 
> On Fri, Mar 03, 2006 at 02:23:32PM +0100, johan@capvert.se wrote:
> >                                                Hi!
> >
> >
> > I?m not a subscriber yet, but I tried to find out what
> distribution/kernel
> > you?re using, or if you got your own build?
> XORP isn't kernel/distribution specific in any
> way. It's being developed on a mixture of
> platforms such as FreeBSD and Linux.
> 
> XORP is regularly compiled on a tinderbox to make
> sure it compiles on the supported platforms.
> 
> The LiveCD is based on FreeBSD (last time I
> checked).
> 
> You could also check out the Vyatta project which
> is a complete router on a CD based on XORP and
> other open source software.
> >
> >                Best regards from/Med vänliga hälsningar från
> >
> >                                  Johan Kragsterman
> Hälsningar,
> Kristian
> 
> 
> 
> 

From kristian@juniks.net  Wed Mar  8 22:31:38 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Wed, 8 Mar 2006 23:31:38 +0100
Subject: [Xorp-hackers] OSPF auth...
Message-ID: <20060308223137.GE7965@juniks.net>

The configuration of authentication looks something like:
      NEW:
      authentication {
          simple-password: "FOO"
      }
      OR
      authentication {
          md5 1 {             /* KeyID: [0, 255] */
              password: "FOO"
              start-time: "YYYY-MM-DD.HH:MM"
              end-time: "YYYY-MM-DD.HH:MM"
          }
      }

Wouldn't it be nice to specify start and end-time for simple passwords too?
Say you are currently using simple auth and would
like to switch to md5, what better way than too
specify and end-tiem for the simple auth and at
the same time enable md5 authentication?

  Kristian.

From marat@vyatta.com  Thu Mar  9 02:57:14 2006
From: marat@vyatta.com (Marat Nepomnyashy)
Date: Wed, 08 Mar 2006 18:57:14 -0800
Subject: [Xorp-hackers] Patch to add method SlaveConfigTreeNode::set_segname(...)
Message-ID: <440F998A.9090103@vyatta.com>

This is a multi-part message in MIME format.
--------------010904070208090707040605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Pavlin,

Please consider the attached patch file for integration into XORP.  It 
adds a convenience method SlaveConfigTreeNode::set_segname(...) to 
/rtrmgr/slave_conf_tree_node.hh

I'm using this method to set the name of a multi-node 
SlaveConfigTreeNode after I create it.

Thanks,
Marat



--------------010904070208090707040605
Content-Type: text/plain;
 name="patch-sctn-set_segname"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch-sctn-set_segname"

--- ../../xorp/rtrmgr/slave_conf_tree_node.hh	2006-02-28 11:31:11.000000000 -0800
+++ slave_conf_tree_node.hh	2006-03-08 11:31:33.000000000 -0800
@@ -79,6 +79,9 @@
 
     void finalize_commit();
 
+    void set_segname(const std::string new_segname) {
+        _segname = new_segname;
+    }
 protected:
     bool build_command_tree(CommandTree& cmdtree, 
 			    const list<string>& commands, 

--------------010904070208090707040605--

From marat@vyatta.com  Thu Mar  9 03:08:15 2006
From: marat@vyatta.com (Marat Nepomnyashy)
Date: Wed, 08 Mar 2006 19:08:15 -0800
Subject: [Xorp-hackers] Re: Patch to add method SlaveConfigTreeNode::set_segname(...)
In-Reply-To: <440F998A.9090103@vyatta.com>
References: <440F998A.9090103@vyatta.com>
Message-ID: <440F9C1F.6070609@vyatta.com>

This is a multi-part message in MIME format.
--------------090005070304080906090808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Oops,

Forgot the ampersand.  Use this one :)

-- Marat

Marat Nepomnyashy wrote:
> Hi Pavlin,
>
> Please consider the attached patch file for integration into XORP.  It 
> adds a convenience method SlaveConfigTreeNode::set_segname(...) to 
> /rtrmgr/slave_conf_tree_node.hh
>
> I'm using this method to set the name of a multi-node 
> SlaveConfigTreeNode after I create it.
>
> Thanks,
> Marat
>
>
> ------------------------------------------------------------------------
>
> --- ../../xorp/rtrmgr/slave_conf_tree_node.hh	2006-02-28 11:31:11.000000000 -0800
> +++ slave_conf_tree_node.hh	2006-03-08 11:31:33.000000000 -0800
> @@ -79,6 +79,9 @@
>  
>      void finalize_commit();
>  
> +    void set_segname(const std::string new_segname) {
> +        _segname = new_segname;
> +    }
>  protected:
>      bool build_command_tree(CommandTree& cmdtree, 
>  			    const list<string>& commands, 
>   

--------------090005070304080906090808
Content-Type: text/plain;
 name="patch-sctn-set_segname.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch-sctn-set_segname.txt"

--- ../../xorp/rtrmgr/slave_conf_tree_node.hh	2006-02-28 11:31:11.000000000 -0800
+++ slave_conf_tree_node.hh	2006-03-08 11:31:33.000000000 -0800
@@ -79,6 +79,9 @@
 
     void finalize_commit();
 
+    void set_segname(const std::string & new_segname) {
+        _segname = new_segname;
+    }
 protected:
     bool build_command_tree(CommandTree& cmdtree, 
 			    const list<string>& commands, 

--------------090005070304080906090808--

From dave@vyatta.com  Thu Mar  9 21:26:48 2006
From: dave@vyatta.com (Dave Roberts)
Date: Thu, 09 Mar 2006 13:26:48 -0800
Subject: [Xorp-hackers] XRL IPC questions
Message-ID: <44109D98.6070806@vyatta.com>

I have been looking at the XRL mechanism lately and had some questions 
about how it works. I have read both the XRL documentation on the XORP 
site as well as looked at the code, but a bit of confirmation from those 
who know the code in detail would be of assistance. Pointers to docs 
(RTFM) or particular code files that should be investigated also 
appreciated.

1. I'm a bit unclear in how processes interact with the finder to invoke 
XRLs. From what I have read, I think this is the process, but any 
comments or corrections would be much appreciated. The following assumes 
the STCP XRL transport. Let's also assume the XRLs used in the "XORP 
Inter-Process Communication Library Overview" document on the XORP site.
    a. First, a client process makes a TCP connection to 127.0.0.1 (does 
it actually connect to "localhost", going through DNS resolution on 
that, or just to the address directly) on port 19999 (Finder's well 
known port?).
    b. Client sends a request packet to the Finder. The packet containss 
the XRL. Say the XRL is 
"finder://fea/fti/0.1/add_route?net:ipv4net=10.0.0.1/8&gateway:ipv4=192.150.187.1".
    c. The Finder does the resolution and returns a response packet to 
the client over the connection. The response packet contains the same 
sequence number as in the request.
    d. The response data is itself another complete encoded XRL, this 
time resolved. Per the documentation, this would be something like: 
"stcp://192.150.1.5:1992/fti/0.1/add_route?net:ipv4net=10.0.0.1&gateway:ipv4=192.150.1.1".
    e. The client parses this XRL and extracts the addressing information.
    f. The client opens a TCP connection (because of the "stcp" scheme 
in the XRL) to 192.150.1.5 (won't this typically be 127.0.0.1?), port 1992.
    g. The client sends a request packet to the server (in this case the 
FEA process). The request contains the encoded, resolved XRL.
    f. The server sends back a response packet. This packet again has 
matched sequence numbers to the request.
    g. I'm not sure what the response contains? In this case, it would 
seem that no response data is really required, though I haven't looked 
at the add_route API to know for sure. If data is required, is it 
returned in some sort of XRL form, or just as raw XRL atoms?

2. How does a process register with the Finder? I know that it probably 
opens a connection to the Finder and sends it one or more XRLs that 
define the address and port on which it is listening, but I'm not sure 
what those are. Are those XRLs sent on a special connection to the 
finder, or just over the same one on which resolution happens? Do XRLs 
invoked on the Finder itself go through the two-hop resolution process?

3. How many outstanding XRL requests are allowed by a process at one 
time? The IPC library seems to have some limits, but it isn't clear what 
happens when those are exceeded.

4. The IPC Lib Overview document at one point says: "In addition to 
handle XRL registrations and resolutions, the Finder is capable of 
notifying XRL Targets about events it is aware of, like the birth and 
death of other XRL Targets. The Finder exposes an XRL interface for this 
purpose and is able to invoke XRLs on XRL Targets to perform the 
noti�cation. A special tunneling mechanism exists in the communication 
protocol used to communicate with the Finder for this purpose. The 
details of this communication will be expanded upon later on [XXX in a 
later edit to this document]."

Are there any more documents for this? Can somebody give an overview of 
how this works?

Thanks,

-- Dave

From pavlin@icir.org  Thu Mar  9 22:18:08 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 09 Mar 2006 14:18:08 -0800
Subject: [Xorp-hackers] Announcing XORP Release 1.2
Message-ID: <200603092218.k29MI80i077022@possum.icir.org>

On behalf of the entire XORP team, I'm delighted to announce the XORP
1.2 Release, which is now available from <http://www.xorp.org>.

The major new features with this release are:

* OSPF implementation.
* Complete integration of the routing policy mechanism.
* Windows support.

In addition, this release contains numerous bug fixes.

There are still a number of non-critical bugs that we know about which
will not be addressed until the 1.3 release; these are documented in
the errata section below and in XORP Bugzilla database
<http://www.xorp.org/bugzilla/index.cgi>.

In general, to test XORP, we run automated regression tests on a daily
basis with various operating systems and compilers. We also run a
number of PCs as XORP routers. We have enabled as many protocols as
feasible on those routers to test protocol interactions (for example a
BGP IPv6 multicast feed being used by PIM-SM). In addition, automated
scripts are run to externally toggle BGP peerings. Finally, we have
automated scripts that interact directly with the xorpsh to change the
configuration settings.

We have put significant effort into testing but obviously we have not
found all the problems. This is where you can help us to make XORP
more stable, by downloading and using it!

As always we'd welcome your comments - xorp-users@xorp.org is the
right place for general discussion, and private feedback to the XORP
core team can be sent to feedback@xorp.org.

 - The XORP Team

P.S.
Release notes and errata are included below.

------------------------------------------------------------------
		XORP RELEASE NOTES

Release 1.2 (2006/03/08)
=========================
  ALL:
    - Numerous improvements, bug fixes and cleanup.

    - The third-party ospfd implementation is replaced with a new
      OSPF implementation developed from scratch.

    - The integration of the routing policy mechanism with the rest of
      the system is completed.

    - XORP now builds on Windows Server 2003 (Service Pack 1),
      amd64+FreeBSD-6.0, FreeBSD-6.1 (BETA3), NetBSD-3.0, OpenBSD-2.8,
      MacOS X 10.4.5, Linux Fedora Core4 (among others).

  CONFIGURATION:
    - Addition of new interface related configuration statement:
      * restore-original-config-on-shutdown: <bool>

      This optional statement is used to enable the restoring of the
      original network interface information on shutdown.

    - Addition of new PIM-SM related configuration statements:

      * enable-ip-router-alert-option-check: <bool>

      This optional statement is used to enable the IP Router Alert option
      check per virtual interface.

      * cand-bsr-by-vif-addr: <IPv4 | IPv6>
        and
      * cand-rp-by-vif-addr: <IPv4 | IPv6>

      Those optional statements are used together with cand-bsr-by-vif-name
      and cand-rp-by-vif-name respectively to specify the particular
      IP address on the configured vif. If they are omitted, a domain-wide
      address (if exists) that belongs to that interface is chosen by the
      router itself.

      * hello-period: <u32>

      This optional statement is used to configure the PIM Hello messages
      period (in seconds).

      * hello-triggered-delay: <u32>

      This optional statement is used to configure the randomized triggered
      delay of the PIM Hello messages (in seconds).

    - Addition of new MLD/IGMP related configuration statements:

      * version: <u32>

      This optional statement is used to configure the MLD/IGMP
      protocol version per virtual interface.

      * enable-ip-router-alert-option-check: <bool>

      This optional statement is used to enable the IP Router Alert option
      check per virtual interface.

      * query-interval: <u32>

      This optional statement is used to specify (per virtual interface)
      the interval between general queries.

      * query-last-member-interval: <u32>

      This optional statement is used to specify (per virtual interface)
      the maximum response time inserted into group-specific queries sent
      in response to leave group messages.

      * query-response-interval: <u32>

      This optional statement is used to specify (per virtual interface)
      the maximum response time inserted into the periodic general queries.

      * robust-count: <u32>

      This optional statement is used to specify (per virtual interface)
      the robustness variable count that allows tuning for the expected
      packet loss on a subnet.

    - Addition of support for user environmental variables CFLAGS_END and
      CXXFLAGS_END. Those variables can be used to specify the compiler
      flags (for the C and C++ compiler respectively) that must be after
      all other flags.

  LIBXORP:
    - Various improvements in the RunCommand implementation.

  LIBXIPC:
    - No significant changes.

  LIBFEACLIENT:
    - No significant changes.

  XRL:
    - No significant changes.

  RTRMGR:
    - Generalization of the %mandatory keyword syntax so now it can
      be used to specify any node or variable (multi-value nodes excluded)
      in the configuration tree. Previously it could be used to specify
      only configuration child nodes or variables.

    - Addition of support for read-only, permanent and user-hidden nodes
      (specified respectively by the new %read-only, %permanent and
       %user-hidden template commands).

    - Modification of the %allow and %allow-range semantics so a help string
      can be supplied for each allowed value or range.

    - Removal of the mechanism for specifying the hook for saving
      a configuration file (the "-s <app>" command-line argument).
      The mechanism is broken and is superseded by the rtrmgr template
      support for running external programs.

    - Various other improvements and bug fixes.

  XORPSH:
    - Addition of support to run xorpsh in non-interactive mode.

    - Modification of the configurational mode "show" command
      so now it displays parameters only if their value is not
      same as the default value.

    - Addition of command "show -all" that shows the complete configuration
      including the parameters with default values.

    - Modification to the "show" command output: in configuration mode
      all deleted (and uncommitted) entries are prefixed with "-".

    - Modification of the default operational and configuration mode
      prompts to "user@hostname> " and "user@hostname# " respectively.

    - Addition of support to modify the operational and configuration
      mode prompts by environmental variables
      XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION
      respectively.

    - Addition of support for command-line completion for allowed values.

    - Various other improvements and bug fixes.

  POLICY:
    - Several bug fixes.

  FEA/MFEA:
    - Addition of RawSocket{4,6} generic abstraction that is not
      multicast-specific.

  RIB:
    - Addition of support for displaying the routing tables in brief,
      detailed and terse format. The default format is "brief".

   - Few bug fixes.

  RIP:
    - The syntax for configuring the authentication mechanism has changed:

      OLD:
      authentication {
          type: "plaintext"
          password: "FOO"
      }
      OR
      authentication {
          type: "md5"
          password: "FOO"
      }

      NEW:
      authentication {
          simple-password: "FOO"
      }
      OR
      authentication {
          md5 1 {             /* KeyID: [0, 255] */
              password: "FOO"
              start-time: "YYYY-MM-DD.HH:MM"
              end-time: "YYYY-MM-DD.HH:MM"
          }
      }

    - Several bug fixes.

  OSPF:
    - Initial implementation of OSPF that replaces the third-party ospfd.

  BGP:
    - The network4/network6 directives have been deprecated.
      If you wish to inject static routes into BGP, you must now add
      these routes to the static_routes protocol block, and then configure
      the policy engine to redistribute them to BGP.

    - Proper support for policy filters.

    - Addition of support for route flap damping.

    - Addition of support for route aggregation.

    - Addition of support for route reflection.

    - Addition of support for confederations.

    - Bug fix to correctly handle connection collisions.

    - Addition of default support for NO_EXPORT, NO_ADVERTISE, and
      NO_EXPORT_SUBCONFED well-known communities.

    - Addition of the capability to reconfigure a peering (e.g., from IBGP to
      EBGP) which requires re-configuring the default filters.

    - Numerous bug fixes that should greatly improve stability.

  STATIC_ROUTES:
    -  Several bug fixes.

  MLD/IGMP:
    - No significant changes.

  PIM-SM:
    - Updated to support the lastest PIM-SM specification
      (draft-ietf-pim-sm-v2-new-11.{ps,txt}).

    - Addition of support to disable the "wrong iif" kernel upcall on
      interfaces we don't need to monitor.

    - Bug fix related to the handling of the deleted MRIB entries.

    - Bug fix related to transmitting AssertCancel message when
      a PIM configured interface is gracefully shutdown.

  FIB2MRIB:
    - Several bug fixes.

  CLI:
    - Various improvements and bug fixes.

  SNMP:
    - No significant changes.

------------------------------------------------------------------
		XORP ERRATA

  ALL:
    - Parallel building (e.g., "gmake -j 4") may fail on multi-CPU
      machines. The simplest work-around is to rerun gmake or not to use
      the -j flag.

    - The following compiler is known to be buggy, and should not be used
      to compile XORP:
        gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD]
      A newer compiler such as the following should be used instead:
        gcc34 (GCC) 3.4.2 20040827 (prerelease) [FreeBSD]

    - If you run BGP, RIB, FIB2MRIB, and PIM-SM at the same time,
      the propagation latency for the BGP routes to reach the kernel
      is increased. We are investigating the problem.

  LIBXORP:
    - No known issues.

  LIBXIPC:
    - No known issues.

  LIBFEACLIENT:
    - No known issues.

  XRL:
    - No known issues.

  RTRMGR:
    - There are several known issues, but none of them is considered
      critical. The list of known issues is available from:

        http://www.xorp.org/bugzilla/query.cgi

    - Using the rtrmgr "-r" command-line option to restart processes
      that have failed does not work if a process fails while being
      reconfigured via xorpsh. If that happens, the rtrmgr itself may
      coredump. Therefore, using the "-r" command-line option is not
      recommended! Also, note that a process that has been killed by
      SIGTERM or SIGKILL will not be restarted (this is a feature rather
      than a bug). Ideally, we want to monitor the processes status
      using the finder rather than the forked children process status,
      therefore in the future when we have a more robust implementation
      the "-r" switch will be removed and will be enabled by default.

  XORPSH:
    - There are several known issues, but none of them is considered
      critical. The list of known issues is available from:

        http://www.xorp.org/bugzilla/query.cgi

  FEA/MFEA:
    - On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel
      2.6.5-1.358), some of the tests may fail (with or without an error
      message), but no coredump image. Some of those failures can be
      contributed to a kernel problem. E.g., running "dmesg" can show
      kernel "Oops" messages like:

        Unable to handle kernel NULL pointer dereference at virtual
        address 00000000 printing eip:
        ...

      This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME)
      which itself is called by if_indextoname(3). Currently, there 
      is no known solution, but it appears the problem may have been
      fixed for more recent Linux kernel versions:

        https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697

    - The mechanism for tracking the network interface link status
      may not work for the following OS-es because the kernel for those
      systems does not provide a mechanism for asynchronous notification
      of userland programs when the link status changes: FreeBSD-5.2 and
      earlier and MacOS X (note: if the Windows kernel supports this
      feature, it is not used yet in XORP). Though, for those systems
      the link status should be read properly on startup.

  RIB:
    - In some rare cases, the RIB may fail to delete an existing route:

        http://www.xorp.org/bugzilla/show_bug.cgi?id=62

      We are aware of the issue and will attempt to fix it in the
      future.

  RIP:
    - No known issues.

  OSPF:
    - There are several known issues, but none of them is considered
      critical. The list of known issues is available from:

        http://www.xorp.org/bugzilla/query.cgi

  BGP:
    - If the RIB bug above (failure to delete an existing route) is
      triggered by BGP, then the deletion failure error received by
      BGP from the RIB is considered by BGP as a fatal error. This is
      not a BGP problem, but a RIB problem that will be fixed in the
      future.

    - The BGP configuration mandates that an IPv4 nexthop must be
      supplied. Unfortunately it is necessary to provide an IPv4 nexthop
      even for an IPv6 only peering. Even more unfortunately it is not
      possible to force the IPv6 nexthop.

    - It is *essential* for an IPv6 peering that an IPv6 nexthop is
      provided. Unfortunately the configuration does not enforce this
      requrement. This will be fixed in the future.

    - If a policy is configured for marking routes as candidates for
      aggregation, and an update for such a route arrives while a
      peering is being brought up (XORP is dumping routes to it), a race
      condition can occur which is considered by BGP as a fatal error.
      The problem was observed only on IPv6 peerings, and will be fixed
      in the future.

  STATIC_ROUTES:
    - No known issues.
      
  MLD/IGMP:
    - If MLD/IGMP is started on Linux with a relatively large number of
      interfaces (e.g., on the order of 20), then it may fail with the
      following error:

        [ 2004/06/14 12:58:56  ERROR test_pim:16548 MFEA +666
        mfea_proto_comm.cc join_multicast_group ] Cannot join group
        224.0.0.2 on vif eth8: No buffer space available

      The solution is to increase the multicast group membership limit.
      E.g., to increase the value from 20 (the default) to 200, run as a
      root:

        echo 200 > /proc/sys/net/ipv4/igmp_max_memberships

  PIM-SM:
    - If the kernel does not support PIM-SM, or if PIM-SM is not enabled
      in the kernel, then running PIM-SM will fail with the following
      error message:

        [ 2004/06/12 10:26:41  ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc
        start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported

    - On Linux, if the unicast Reverse Path Forwarding information is
      different from the multicast Reverse Path Forwarding information,
      the Reverse Path Filtering should be disabled. E.g., as root:

        echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

      OR

        echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
        echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
        ...

      Otherwise, the router will ignore packets if they don't arrive on
      the reverse-path interface. For more information about Reverse
      Path Filtering see:

        http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html

    - Currently, the PIM-SM implementation does not support unnumbered
      point-to-point links. Furthermore, even on numbered point-to-point
      links the next-hop information in the routing entries should use
      an IP address instead of an interface name. For example,
      if there is a GRE tunnel on Linux and if we want to add a route
      that uses that tunnel, we should use a command like:

        route add -net <target> gw <IP address of other side of GRE tunnel>

      instead of:

        route add -net <target> <GRE interface name>

  FIB2MRIB:
    - No known issues.

  CLI:
    - No known issues.

  SNMP:
    - On some versions of Linux, there are some bugs in net-snmp
      versions 5.0.8 and 5.0.9, which prevent dynamic loading from
      working. See the following URL for links to the net-snmp
      patches that solve the problems:

        http://www.xorp.org/snmp.html

    - Version 5.1 of net-snmp requires a simple modification, otherwise
      XORP will fail to compile.
      See the following URL for a link to the net-snmp patch that solves
      the problems:

         http://www.xorp.org/snmp.html 

From pavlin@icir.org  Fri Mar 10 00:09:09 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 09 Mar 2006 16:09:09 -0800
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: Message from Kristian Larsson <kristian@juniks.net>
 of "Wed, 08 Mar 2006 23:31:38 +0100." <20060308223137.GE7965@juniks.net>
Message-ID: <200603100009.k2A099Ew086477@possum.icir.org>

> 
> The configuration of authentication looks something like:
>       NEW:
>       authentication {
>           simple-password: "FOO"
>       }
>       OR
>       authentication {
>           md5 1 {             /* KeyID: [0, 255] */
>               password: "FOO"
>               start-time: "YYYY-MM-DD.HH:MM"
>               end-time: "YYYY-MM-DD.HH:MM"
>           }
>       }
> 
> Wouldn't it be nice to specify start and end-time for simple passwords too?
> Say you are currently using simple auth and would
> like to switch to md5, what better way than too
> specify and end-tiem for the simple auth and at
> the same time enable md5 authentication?

Good question!
When I was updating the front-end authentication interface for RIP
(and then porting it to OSPF), initially I considered adding start
and end-time for simple passwords as well. However, at the end I
decided not to do it for the following reasons:

 * In Juniper there is no start/end time for simple passwords.
   In fact, they don't have even end-time for md5.

 * To have the switchover working properly you need to have both
   sides agree on some additional rules about when to start and stop
   accepting or transmitting the new/old key(s). We need such rules
   to cover cases like clocks that are not synchronized, etc.
   Such rules do not exist (in RFC or a similar document) for
   switching between a simple password and md5.

 * Even if we exclude the simple passwords from the picture, the
   whole mechanism of gradually switching from one MD5 password
   to another is a bit fuzzy with some holes (e.g., see Sections 4.2
   and 4.3 in RFC 2082). No wonder the whole key switchover
   mechanism is not used for RIPng.

 * The simple password mechanism is not secure at all so people
   should be discouraged from using it :)

Pavlin

From pavlin@icir.org  Fri Mar 10 02:02:15 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 09 Mar 2006 18:02:15 -0800
Subject: [Xorp-hackers] Patch to add method SlaveConfigTreeNode::set_segname(...)
In-Reply-To: Message from Marat Nepomnyashy <marat@vyatta.com>
 of "Wed, 08 Mar 2006 18:57:14 PST." <440F998A.9090103@vyatta.com>
Message-ID: <200603100202.k2A22F2Z087650@possum.icir.org>

> Please consider the attached patch file for integration into XORP.  It 
> adds a convenience method SlaveConfigTreeNode::set_segname(...) to 
> /rtrmgr/slave_conf_tree_node.hh
> 
> I'm using this method to set the name of a multi-node 
> SlaveConfigTreeNode after I create it.

Marat,

Why is the segname of a child allowed to change?
It should be assigned when the node is created and shouldn't change
after that.
If the only time you need to set the segname is when you create the
node, then it should be added as an argument to the appropriate
constructor.

Pavlin

From mhorn@vyatta.com  Fri Mar 10 02:19:16 2006
From: mhorn@vyatta.com (Mike Horn)
Date: Thu, 9 Mar 2006 18:19:16 -0800 (PST)
Subject: [Xorp-hackers] Announcing XORP Release 1.2
Message-ID: <29662751.3371141957156751.JavaMail.root@mail.vyatta.com>

Hi Pavlin,

Congratulations on getting 1.2 released!  I know the XORP team has been working really hard and the number of bug fixes and enhancements in this release is truly impressive.  Thanks to everyone that helped make this happen!

-mike

----- Original Message -----
From: Pavlin Radoslavov <pavlin@icir.org>
To: xorp-announce@xorp.org
Cc: xorp-users@xorp.org, xorp-hackers@xorp.org
Sent: Thursday, March 9, 2006 3:18:08 PM GMT-0700
Subject: [Xorp-hackers] Announcing XORP Release 1.2

On behalf of the entire XORP team, I'm delighted to announce the XORP
1.2 Release, which is now available from <http://www.xorp.org>.

The major new features with this release are:

* OSPF implementation.
* Complete integration of the routing policy mechanism.
* Windows support.

In addition, this release contains numerous bug fixes.

There are still a number of non-critical bugs that we know about which
will not be addressed until the 1.3 release; these are documented in
the errata section below and in XORP Bugzilla database
<http://www.xorp.org/bugzilla/index.cgi>.

In general, to test XORP, we run automated regression tests on a daily
basis with various operating systems and compilers. We also run a
number of PCs as XORP routers. We have enabled as many protocols as
feasible on those routers to test protocol interactions (for example a
BGP IPv6 multicast feed being used by PIM-SM). In addition, automated
scripts are run to externally toggle BGP peerings. Finally, we have
automated scripts that interact directly with the xorpsh to change the
configuration settings.

We have put significant effort into testing but obviously we have not
found all the problems. This is where you can help us to make XORP
more stable, by downloading and using it!

As always we'd welcome your comments - xorp-users@xorp.org is the
right place for general discussion, and private feedback to the XORP
core team can be sent to feedback@xorp.org.

 - The XORP Team

P.S.
Release notes and errata are included below.

------------------------------------------------------------------
		XORP RELEASE NOTES

Release 1.2 (2006/03/08)
=========================
  ALL:
    - Numerous improvements, bug fixes and cleanup.

    - The third-party ospfd implementation is replaced with a new
      OSPF implementation developed from scratch.

    - The integration of the routing policy mechanism with the rest of
      the system is completed.

    - XORP now builds on Windows Server 2003 (Service Pack 1),
      amd64+FreeBSD-6.0, FreeBSD-6.1 (BETA3), NetBSD-3.0, OpenBSD-2.8,
      MacOS X 10.4.5, Linux Fedora Core4 (among others).

  CONFIGURATION:
    - Addition of new interface related configuration statement:
      * restore-original-config-on-shutdown: <bool>

      This optional statement is used to enable the restoring of the
      original network interface information on shutdown.

    - Addition of new PIM-SM related configuration statements:

      * enable-ip-router-alert-option-check: <bool>

      This optional statement is used to enable the IP Router Alert option
      check per virtual interface.

      * cand-bsr-by-vif-addr: <IPv4 | IPv6>
        and
      * cand-rp-by-vif-addr: <IPv4 | IPv6>

      Those optional statements are used together with cand-bsr-by-vif-name
      and cand-rp-by-vif-name respectively to specify the particular
      IP address on the configured vif. If they are omitted, a domain-wide
      address (if exists) that belongs to that interface is chosen by the
      router itself.

      * hello-period: <u32>

      This optional statement is used to configure the PIM Hello messages
      period (in seconds).

      * hello-triggered-delay: <u32>

      This optional statement is used to configure the randomized triggered
      delay of the PIM Hello messages (in seconds).

    - Addition of new MLD/IGMP related configuration statements:

      * version: <u32>

      This optional statement is used to configure the MLD/IGMP
      protocol version per virtual interface.

      * enable-ip-router-alert-option-check: <bool>

      This optional statement is used to enable the IP Router Alert option
      check per virtual interface.

      * query-interval: <u32>

      This optional statement is used to specify (per virtual interface)
      the interval between general queries.

      * query-last-member-interval: <u32>

      This optional statement is used to specify (per virtual interface)
      the maximum response time inserted into group-specific queries sent
      in response to leave group messages.

      * query-response-interval: <u32>

      This optional statement is used to specify (per virtual interface)
      the maximum response time inserted into the periodic general queries.

      * robust-count: <u32>

      This optional statement is used to specify (per virtual interface)
      the robustness variable count that allows tuning for the expected
      packet loss on a subnet.

    - Addition of support for user environmental variables CFLAGS_END and
      CXXFLAGS_END. Those variables can be used to specify the compiler
      flags (for the C and C++ compiler respectively) that must be after
      all other flags.

  LIBXORP:
    - Various improvements in the RunCommand implementation.

  LIBXIPC:
    - No significant changes.

  LIBFEACLIENT:
    - No significant changes.

  XRL:
    - No significant changes.

  RTRMGR:
    - Generalization of the %mandatory keyword syntax so now it can
      be used to specify any node or variable (multi-value nodes excluded)
      in the configuration tree. Previously it could be used to specify
      only configuration child nodes or variables.

    - Addition of support for read-only, permanent and user-hidden nodes
      (specified respectively by the new %read-only, %permanent and
       %user-hidden template commands).

    - Modification of the %allow and %allow-range semantics so a help string
      can be supplied for each allowed value or range.

    - Removal of the mechanism for specifying the hook for saving
      a configuration file (the "-s <app>" command-line argument).
      The mechanism is broken and is superseded by the rtrmgr template
      support for running external programs.

    - Various other improvements and bug fixes.

  XORPSH:
    - Addition of support to run xorpsh in non-interactive mode.

    - Modification of the configurational mode "show" command
      so now it displays parameters only if their value is not
      same as the default value.

    - Addition of command "show -all" that shows the complete configuration
      including the parameters with default values.

    - Modification to the "show" command output: in configuration mode
      all deleted (and uncommitted) entries are prefixed with "-".

    - Modification of the default operational and configuration mode
      prompts to "user@hostname> " and "user@hostname# " respectively.

    - Addition of support to modify the operational and configuration
      mode prompts by environmental variables
      XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION
      respectively.

    - Addition of support for command-line completion for allowed values.

    - Various other improvements and bug fixes.

  POLICY:
    - Several bug fixes.

  FEA/MFEA:
    - Addition of RawSocket{4,6} generic abstraction that is not
      multicast-specific.

  RIB:
    - Addition of support for displaying the routing tables in brief,
      detailed and terse format. The default format is "brief".

   - Few bug fixes.

  RIP:
    - The syntax for configuring the authentication mechanism has changed:

      OLD:
      authentication {
          type: "plaintext"
          password: "FOO"
      }
      OR
      authentication {
          type: "md5"
          password: "FOO"
      }

      NEW:
      authentication {
          simple-password: "FOO"
      }
      OR
      authentication {
          md5 1 {             /* KeyID: [0, 255] */
              password: "FOO"
              start-time: "YYYY-MM-DD.HH:MM"
              end-time: "YYYY-MM-DD.HH:MM"
          }
      }

    - Several bug fixes.

  OSPF:
    - Initial implementation of OSPF that replaces the third-party ospfd.

  BGP:
    - The network4/network6 directives have been deprecated.
      If you wish to inject static routes into BGP, you must now add
      these routes to the static_routes protocol block, and then configure
      the policy engine to redistribute them to BGP.

    - Proper support for policy filters.

    - Addition of support for route flap damping.

    - Addition of support for route aggregation.

    - Addition of support for route reflection.

    - Addition of support for confederations.

    - Bug fix to correctly handle connection collisions.

    - Addition of default support for NO_EXPORT, NO_ADVERTISE, and
      NO_EXPORT_SUBCONFED well-known communities.

    - Addition of the capability to reconfigure a peering (e.g., from IBGP to
      EBGP) which requires re-configuring the default filters.

    - Numerous bug fixes that should greatly improve stability.

  STATIC_ROUTES:
    -  Several bug fixes.

  MLD/IGMP:
    - No significant changes.

  PIM-SM:
    - Updated to support the lastest PIM-SM specification
      (draft-ietf-pim-sm-v2-new-11.{ps,txt}).

    - Addition of support to disable the "wrong iif" kernel upcall on
      interfaces we don't need to monitor.

    - Bug fix related to the handling of the deleted MRIB entries.

    - Bug fix related to transmitting AssertCancel message when
      a PIM configured interface is gracefully shutdown.

  FIB2MRIB:
    - Several bug fixes.

  CLI:
    - Various improvements and bug fixes.

  SNMP:
    - No significant changes.

------------------------------------------------------------------
		XORP ERRATA

  ALL:
    - Parallel building (e.g., "gmake -j 4") may fail on multi-CPU
      machines. The simplest work-around is to rerun gmake or not to use
      the -j flag.

    - The following compiler is known to be buggy, and should not be used
      to compile XORP:
        gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD]
      A newer compiler such as the following should be used instead:
        gcc34 (GCC) 3.4.2 20040827 (prerelease) [FreeBSD]

    - If you run BGP, RIB, FIB2MRIB, and PIM-SM at the same time,
      the propagation latency for the BGP routes to reach the kernel
      is increased. We are investigating the problem.

  LIBXORP:
    - No known issues.

  LIBXIPC:
    - No known issues.

  LIBFEACLIENT:
    - No known issues.

  XRL:
    - No known issues.

  RTRMGR:
    - There are several known issues, but none of them is considered
      critical. The list of known issues is available from:

        http://www.xorp.org/bugzilla/query.cgi

    - Using the rtrmgr "-r" command-line option to restart processes
      that have failed does not work if a process fails while being
      reconfigured via xorpsh. If that happens, the rtrmgr itself may
      coredump. Therefore, using the "-r" command-line option is not
      recommended! Also, note that a process that has been killed by
      SIGTERM or SIGKILL will not be restarted (this is a feature rather
      than a bug). Ideally, we want to monitor the processes status
      using the finder rather than the forked children process status,
      therefore in the future when we have a more robust implementation
      the "-r" switch will be removed and will be enabled by default.

  XORPSH:
    - There are several known issues, but none of them is considered
      critical. The list of known issues is available from:

        http://www.xorp.org/bugzilla/query.cgi

  FEA/MFEA:
    - On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel
      2.6.5-1.358), some of the tests may fail (with or without an error
      message), but no coredump image. Some of those failures can be
      contributed to a kernel problem. E.g., running "dmesg" can show
      kernel "Oops" messages like:

        Unable to handle kernel NULL pointer dereference at virtual
        address 00000000 printing eip:
        ...

      This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME)
      which itself is called by if_indextoname(3). Currently, there 
      is no known solution, but it appears the problem may have been
      fixed for more recent Linux kernel versions:

        https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697

    - The mechanism for tracking the network interface link status
      may not work for the following OS-es because the kernel for those
      systems does not provide a mechanism for asynchronous notification
      of userland programs when the link status changes: FreeBSD-5.2 and
      earlier and MacOS X (note: if the Windows kernel supports this
      feature, it is not used yet in XORP). Though, for those systems
      the link status should be read properly on startup.

  RIB:
    - In some rare cases, the RIB may fail to delete an existing route:

        http://www.xorp.org/bugzilla/show_bug.cgi?id=62

      We are aware of the issue and will attempt to fix it in the
      future.

  RIP:
    - No known issues.

  OSPF:
    - There are several known issues, but none of them is considered
      critical. The list of known issues is available from:

        http://www.xorp.org/bugzilla/query.cgi

  BGP:
    - If the RIB bug above (failure to delete an existing route) is
      triggered by BGP, then the deletion failure error received by
      BGP from the RIB is considered by BGP as a fatal error. This is
      not a BGP problem, but a RIB problem that will be fixed in the
      future.

    - The BGP configuration mandates that an IPv4 nexthop must be
      supplied. Unfortunately it is necessary to provide an IPv4 nexthop
      even for an IPv6 only peering. Even more unfortunately it is not
      possible to force the IPv6 nexthop.

    - It is *essential* for an IPv6 peering that an IPv6 nexthop is
      provided. Unfortunately the configuration does not enforce this
      requrement. This will be fixed in the future.

    - If a policy is configured for marking routes as candidates for
      aggregation, and an update for such a route arrives while a
      peering is being brought up (XORP is dumping routes to it), a race
      condition can occur which is considered by BGP as a fatal error.
      The problem was observed only on IPv6 peerings, and will be fixed
      in the future.

  STATIC_ROUTES:
    - No known issues.
      
  MLD/IGMP:
    - If MLD/IGMP is started on Linux with a relatively large number of
      interfaces (e.g., on the order of 20), then it may fail with the
      following error:

        [ 2004/06/14 12:58:56  ERROR test_pim:16548 MFEA +666
        mfea_proto_comm.cc join_multicast_group ] Cannot join group
        224.0.0.2 on vif eth8: No buffer space available

      The solution is to increase the multicast group membership limit.
      E.g., to increase the value from 20 (the default) to 200, run as a
      root:

        echo 200 > /proc/sys/net/ipv4/igmp_max_memberships

  PIM-SM:
    - If the kernel does not support PIM-SM, or if PIM-SM is not enabled
      in the kernel, then running PIM-SM will fail with the following
      error message:

        [ 2004/06/12 10:26:41  ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc
        start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported

    - On Linux, if the unicast Reverse Path Forwarding information is
      different from the multicast Reverse Path Forwarding information,
      the Reverse Path Filtering should be disabled. E.g., as root:

        echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

      OR

        echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
        echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
        ...

      Otherwise, the router will ignore packets if they don't arrive on
      the reverse-path interface. For more information about Reverse
      Path Filtering see:

        http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html

    - Currently, the PIM-SM implementation does not support unnumbered
      point-to-point links. Furthermore, even on numbered point-to-point
      links the next-hop information in the routing entries should use
      an IP address instead of an interface name. For example,
      if there is a GRE tunnel on Linux and if we want to add a route
      that uses that tunnel, we should use a command like:

        route add -net <target> gw <IP address of other side of GRE tunnel>

      instead of:

        route add -net <target> <GRE interface name>

  FIB2MRIB:
    - No known issues.

  CLI:
    - No known issues.

  SNMP:
    - On some versions of Linux, there are some bugs in net-snmp
      versions 5.0.8 and 5.0.9, which prevent dynamic loading from
      working. See the following URL for links to the net-snmp
      patches that solve the problems:

        http://www.xorp.org/snmp.html

    - Version 5.1 of net-snmp requires a simple modification, otherwise
      XORP will fail to compile.
      See the following URL for a link to the net-snmp patch that solves
      the problems:

         http://www.xorp.org/snmp.html 
_______________________________________________
Xorp-hackers mailing list
Xorp-hackers@icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

From kristian@juniks.net  Fri Mar 10 13:50:46 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Fri, 10 Mar 2006 14:50:46 +0100
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: <200603100009.k2A099Ew086477@possum.icir.org>
References: <kristian@juniks.net> <20060308223137.GE7965@juniks.net> <200603100009.k2A099Ew086477@possum.icir.org>
Message-ID: <20060310135046.GJ24723@juniks.net>

On Thu, Mar 09, 2006 at 04:09:09PM -0800, Pavlin Radoslavov wrote:
> > 
> > The configuration of authentication looks something like:
> >       NEW:
> >       authentication {
> >           simple-password: "FOO"
> >       }
> >       OR
> >       authentication {
> >           md5 1 {             /* KeyID: [0, 255] */
> >               password: "FOO"
> >               start-time: "YYYY-MM-DD.HH:MM"
> >               end-time: "YYYY-MM-DD.HH:MM"
> >           }
> >       }
> > 
> > Wouldn't it be nice to specify start and end-time for simple passwords too?
> > Say you are currently using simple auth and would
> > like to switch to md5, what better way than too
> > specify and end-tiem for the simple auth and at
> > the same time enable md5 authentication?
> 
> Good question!
> When I was updating the front-end authentication interface for RIP
> (and then porting it to OSPF), initially I considered adding start
> and end-time for simple passwords as well. However, at the end I
> decided not to do it for the following reasons:
> 
>  * In Juniper there is no start/end time for simple passwords.
>    In fact, they don't have even end-time for md5.
Well, this is not a juniper and we should only
pick the good parts from juniper and improve on
the bad ones.
> 
>  * To have the switchover working properly you need to have both
>    sides agree on some additional rules about when to start and stop
>    accepting or transmitting the new/old key(s). We need such rules
>    to cover cases like clocks that are not synchronized, etc.
>    Such rules do not exist (in RFC or a similar document) for
>    switching between a simple password and md5.
Of course, clocks would need to be synchronized
and this would be up to the operator of the
equipment. We use NTP on all our routers and with
OSPF hello timer of 10 seconds there is quite a
window in between in which you can switch key.
> 
>  * Even if we exclude the simple passwords from the picture, the
>    whole mechanism of gradually switching from one MD5 password
>    to another is a bit fuzzy with some holes (e.g., see Sections 4.2
>    and 4.3 in RFC 2082). No wonder the whole key switchover
>    mechanism is not used for RIPng.
Well, you have despite the fuzziness implemented
md5 key switchover so why not for simple auth?
> 
>  * The simple password mechanism is not secure at all so people
>    should be discouraged from using it :)
Yupp, it sure is. What I thought was that it would
be nice to help people transition from simple
auth. My previous employeer used simple
authentication due to old hardware that didn't
support ospf. All that old equipment had been
upgraded but the job of switching was deemed too
risky and too complex.


Regards,
Kristian

From marat@vyatta.com  Fri Mar 10 18:15:03 2006
From: marat@vyatta.com (Marat Nepomnyashy)
Date: Fri, 10 Mar 2006 10:15:03 -0800
Subject: [Xorp-hackers] Patch to add method SlaveConfigTreeNode::set_segname(...)
References: <200603100202.k2A22F2Z087650@possum.icir.org>
Message-ID: <004301c6446e$8e0f5a60$6402a8c0@CPQ16151965929>

Hi Pavlin,

This method is intended for setting or changing the name of a newly created 
multi-node.  After creating them, I either set the value if it is a regular 
node, or the name if it is a multi-node.  Multi-nodes being added  that have 
not yet been committed can also have their name changed without having to 
recreate their child nodes.

-- Marat

----- Original Message ----- 
From: "Pavlin Radoslavov" <pavlin@icir.org>
To: "Marat Nepomnyashy" <marat@vyatta.com>
Cc: "Pavlin Radoslavov" <pavlin@icir.org>; <xorp-hackers@xorp.org>
Sent: Thursday, March 09, 2006 6:02 PM
Subject: Re: [Xorp-hackers] Patch to add method 
SlaveConfigTreeNode::set_segname(...)


>> Please consider the attached patch file for integration into XORP.  It
>> adds a convenience method SlaveConfigTreeNode::set_segname(...) to
>> /rtrmgr/slave_conf_tree_node.hh
>>
>> I'm using this method to set the name of a multi-node
>> SlaveConfigTreeNode after I create it.
>
> Marat,
>
> Why is the segname of a child allowed to change?
> It should be assigned when the node is created and shouldn't change
> after that.
> If the only time you need to set the segname is when you create the
> node, then it should be added as an argument to the appropriate
> constructor.
>
> Pavlin
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers 


From hasso@estpak.ee  Fri Mar 10 14:49:31 2006
From: hasso@estpak.ee (Hasso Tepper)
Date: Fri, 10 Mar 2006 16:49:31 +0200
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: <20060310135046.GJ24723@juniks.net>
References: <kristian@juniks.net> <200603100009.k2A099Ew086477@possum.icir.org> <20060310135046.GJ24723@juniks.net>
Message-ID: <200603101649.31389.hasso@estpak.ee>

Kristian Larsson wrote:
> On Thu, Mar 09, 2006 at 04:09:09PM -0800, Pavlin Radoslavov wrote:
> >  * In Juniper there is no start/end time for simple passwords.
> >    In fact, they don't have even end-time for md5.
>
> Well, this is not a juniper and we should only
> pick the good parts from juniper and improve on
> the bad ones.
>
> >  * To have the switchover working properly you need to have both
> >    sides agree on some additional rules about when to start and stop
> >    accepting or transmitting the new/old key(s). We need such rules
> >    to cover cases like clocks that are not synchronized, etc.
> >    Such rules do not exist (in RFC or a similar document) for
> >    switching between a simple password and md5.

Do start/end times affect accepting keys at all?

> Of course, clocks would need to be synchronized
> and this would be up to the operator of the
> equipment. We use NTP on all our routers and with
> OSPF hello timer of 10 seconds there is quite a
> window in between in which you can switch key.

I'd consider this kind of transition dangerous for my network and would 
never use it.

Juniper has only start-time because there is no need for end-time. Start 
time affects only sending of packets. All configured keys are accepted 
for received packets regardless of start time.

Smooth switch of keys looks like this here:

1) Configure new keys into routers with start time X in the future. X is 
chosen so that you can safely add keys to all routers affected by key 
switch.
2) Monitor affected parts of network closely at X. Doublecheck that all 
works after X.
3) Remove old keys from all affected routers.


regards,

-- 
Hasso Tepper

From pavlin@icir.org  Sat Mar 11 02:12:52 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 10 Mar 2006 18:12:52 -0800
Subject: [Xorp-hackers] Patch to add method SlaveConfigTreeNode::set_segname(...)
In-Reply-To: Message from "Marat Nepomnyashy" <marat@vyatta.com>
 of "Fri, 10 Mar 2006 10:15:03 PST." <004301c6446e$8e0f5a60$6402a8c0@CPQ16151965929>
Message-ID: <200603110212.k2B2CqVT065904@possum.icir.org>

> Hi Pavlin,
> 
> This method is intended for setting or changing the name of a newly created 
> multi-node.  After creating them, I either set the value if it is a regular 
> node, or the name if it is a multi-node.  Multi-nodes being added  that have 
> not yet been committed can also have their name changed without having to 
> recreate their child nodes.

OK, this is the part I still don't understand.
In general, the "segname" of a node is like a permanent name for a
node that should not be modified after it is created. Otherwise,
there could be various surprises. For example, we can have the
multi-value nodes sorted (by their segname), and just changing the
segname on the fly can be a disaster.

It sounds like you create a multi-node and set its segname (say, IP
address "1.1.1.1"). Then, before committing the configuration change
the name of the multi-node is changed (say, "2.2.2.2"), and you want
to just use "set_segname()" to change that node.

To avoid the danger of segname renaming you should create a new
multi-node "2.2.2.2" and then clone the "1.1.1.1" node's subtree to
that node. For that purpose there is already method
ConfigTreeNode::clone_subtree()

Pavlin


> 
> -- Marat
> 
> ----- Original Message ----- 
> From: "Pavlin Radoslavov" <pavlin@icir.org>
> To: "Marat Nepomnyashy" <marat@vyatta.com>
> Cc: "Pavlin Radoslavov" <pavlin@icir.org>; <xorp-hackers@xorp.org>
> Sent: Thursday, March 09, 2006 6:02 PM
> Subject: Re: [Xorp-hackers] Patch to add method 
> SlaveConfigTreeNode::set_segname(...)
> 
> 
> >> Please consider the attached patch file for integration into XORP.  It
> >> adds a convenience method SlaveConfigTreeNode::set_segname(...) to
> >> /rtrmgr/slave_conf_tree_node.hh
> >>
> >> I'm using this method to set the name of a multi-node
> >> SlaveConfigTreeNode after I create it.
> >
> > Marat,
> >
> > Why is the segname of a child allowed to change?
> > It should be assigned when the node is created and shouldn't change
> > after that.
> > If the only time you need to set the segname is when you create the
> > node, then it should be added as an argument to the appropriate
> > constructor.

From pavlin@icir.org  Sat Mar 11 03:21:39 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 10 Mar 2006 19:21:39 -0800
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: Message from Kristian Larsson <kristian@juniks.net>
 of "Fri, 10 Mar 2006 14:50:46 +0100." <20060310135046.GJ24723@juniks.net>
Message-ID: <200603110321.k2B3Ld7S066719@possum.icir.org>

> >  * Even if we exclude the simple passwords from the picture, the
> >    whole mechanism of gradually switching from one MD5 password
> >    to another is a bit fuzzy with some holes (e.g., see Sections 4.2
> >    and 4.3 in RFC 2082). No wonder the whole key switchover
> >    mechanism is not used for RIPng.
> Well, you have despite the fuzziness implemented
> md5 key switchover so why not for simple auth?

We implemented the MD5 key switchover because RFC 2082 requires it :)

Pavlin

From pavlin@icir.org  Sat Mar 11 03:56:13 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 10 Mar 2006 19:56:13 -0800
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: Message from Hasso Tepper <hasso@estpak.ee>
 of "Fri, 10 Mar 2006 16:49:31 +0200." <200603101649.31389.hasso@estpak.ee>
Message-ID: <200603110356.k2B3uDia067092@possum.icir.org>

> > >  * To have the switchover working properly you need to have both
> > >    sides agree on some additional rules about when to start and stop
> > >    accepting or transmitting the new/old key(s). We need such rules
> > >    to cover cases like clocks that are not synchronized, etc.
> > >    Such rules do not exist (in RFC or a similar document) for
> > >    switching between a simple password and md5.
> 
> Do start/end times affect accepting keys at all?

Yes. The keys are not used for transmitting or accepting packets
outside their lifetime.

> > Of course, clocks would need to be synchronized
> > and this would be up to the operator of the
> > equipment. We use NTP on all our routers and with
> > OSPF hello timer of 10 seconds there is quite a
> > window in between in which you can switch key.
> 
> I'd consider this kind of transition dangerous for my network and would 
> never use it.
> 
> Juniper has only start-time because there is no need for end-time. Start 
> time affects only sending of packets. All configured keys are accepted 
> for received packets regardless of start time.

This is different from the mechanism suggested by RFC 2082
(Section 4.3).

Pavlin

> Smooth switch of keys looks like this here:
> 
> 1) Configure new keys into routers with start time X in the future. X is 
> chosen so that you can safely add keys to all routers affected by key 
> switch.
> 2) Monitor affected parts of network closely at X. Doublecheck that all 
> works after X.
> 3) Remove old keys from all affected routers.

From oho@acm.org  Sat Mar 11 17:24:59 2006
From: oho@acm.org (Orion Hodson)
Date: Sat, 11 Mar 2006 09:24:59 -0800
Subject: [Xorp-hackers] XRL IPC questions
In-Reply-To: <44109D98.6070806@vyatta.com>
References: <44109D98.6070806@vyatta.com>
Message-ID: <55D3C465-8A33-4C34-B883-A77B152880F2@acm.org>

Dave

You are on the right lines.  I've attempt to clarify a few points  
below as I am responsible for this portion of the code and the lousy  
documentation.

1. How do processes interact with the Finder?

The Finder is the resolver process.  There is one Finder per XORP  
router instantiation.  The address and port of the Finder are  
configurable (via XRL_FINDER_SERVER_ADDRESS and  
XRL_FINDER_SERVER_PORT environment variables).  The default is  
127.0.0.1/19999 and no DNS resolution is done in the default case  
since a router can't depend on DNS to function.

When a process starts it connects to the Finder and informs it of all  
the XRLs it supports and how they resolve into something the XRL  
library can invoke - a transport type, an transport specific address,  
and a string identifying the method.  For each XRL registered the  
Finder provides the client with a strong name for the method  
supplied.  The registering will only respond to invocations that use  
the  transport, transport address, and the strong name.  The strong  
name is one piece in making network attacks harder, otherwise it'd be  
trivial to craft XRLs remotely and direct them at a XORP router.

A processes connection to the Finder exists for the lifetime of the  
process.  When a process is running and wants to dispatch an XRL it  
first consults it's cache to see if it knows how the XRL resolves  
already.  If it doesn't it queries the Finder to get the resolution  
and caches successful results.  If the caller doesn't have an  
available transport endpoint for the transport protocol with the  
specified address, it creates one, otherwise it simply uses the  
endpoint it already has to send the XRL to the dispatching process.

Arguments are marshalled in XRLs according to the transport type.   
Each argument is represented by an XrlAtom.  For the most commonly  
used transport, simple TCP (stcp), marshalling consists of rendering  
the atom into a host-independent binary format.  Library support  
exists for rendering to ASCII.  In the examples, we present the ASCII  
rendering since it's easier to follow.

When the dispatching process gets the XRL it does an reverse lookup  
from the strong-name to the internal name and then maps that to a  
method call.  In the current implementation, all XRL dispatches  
result in an acknowledgement that contains an error code and dispatch  
results.  Dispatch results are just a list of XrlAtoms marshalled  
according to the transport scheme.

2. How does a process register with the Finder?

The basic process is hopefully outlined in above.

One interesting point to note is that the Finder itself is an XRL  
dispatcher just like other XORP processes.  When a process makes a  
request to the Finder, such as registering an XRL, it sends the  
request as an XRL to the Finder and the finder responds in the usual  
manner - an error code plus result in the form of a list of XrlAtoms.

The transport for the Finder is handled as a special case as trying  
to do otherwise made portions of the code hard to reason about.  The  
protocol used to transport XRLs to the Finder is simply "finder" and  
translates into a TCP connection to the known Finder host and port.

There is no strong-name mapping with Finder XRLs.  The method name  
sent over the wire corresponds to code incable on the finder.   
Otherwise we'd have to deal with how to resolve Finder XRLs.

The first incarnation of the Finder used a totally disjoint  
communication mechanism, but this went against the goal of  
extensibility.  Having the Finder export XRL interfaces makes it  
easier to extend.  We added the Finder Event Notifier interface  
pretty trivially once we'd gotten the basic process-to-Finder  
communication over XRLs.

3. How many outstanding XRL requests are allowed by a process at one  
time?

The library imposes no limit.  Individual protocol families can set  
their own limits.  The UDP transport fails with and  
XrlError::SEND_FAILED if it can't allocate memory to buffer the  
message state.  The TCP transport has no limit coded.  The inproc  
family calls synchronously in-process and has no limits.

This is obviously an area that could be improved.

4. How do Finder notifications work?

The Finder supports the Finder Event Notifier interface.  Clients  
that are interested in receiving birth and death of processes (or  
classes of process) can register their interest through the Finder  
Event Nofifier interface (xorp/xrl/interfaces/ 
finder_event_notifier.xif.  The clients implement the Finder Event  
Observer interface which the Finder uses to notify the clients of the  
birth and death events.

The Finder is aware of all process births because XORP processes must  
connect to it to register their XRLs and resolve XRLs to other  
processes in the system.  The Finder gets notified explicitly of  
clean shutdown and detects crashes and forced quits through the  
socket going bad.

When a process registers its interest in a particular event, it  
specifies the protocol and address of where the notification to be  
sent, ie the process-finder channel is not overloaded to carry this  
information.  This keeps the send-receive semantics the same as other  
protocols - channels carry a request to target and the answer back  
again, we don't support sends in both directions over a channel.

5. Why don't transports support bi-directional requests and responses?

This was a design decision to keep the code as simple as possible.   
Making the code bi-directional isn't a huge delta in complexity, but  
requires some tweaks to the resolution process.  If we wanted to do  
this we'd need to export the notion of identity when resolving XRLs.   
The identity would be associated with each XrlRouter in a process.   
There might be more than one instance of a process running on a  
router and a single process may have multiple XrlRouters which share  
the same address space but are logically separate.  Addressing this  
would reduce the number of open sockets and make some small  
performance improvements, but would need a determined effort to get  
working.

6. What about Finder security?

By default the Finder only accepts connections from the IP addresses  
associated with the host it is running on, ie no external  
connections.  Additional addresses can be added at the command-line.

By dumping packets on the localhost (or local network for a  
distributed XORP router) a hacker could determine the resolutions of  
XRLs and send malicious messages to the XORP processes.  Adding  
encryption to the Finder protocol would raise the bar to this attack.

The Finder XRL transport currently uses a naive packet encoding and  
it is possible to crash the finder by connecting to it and sending it  
junk.  This needs to be addressed and should happen at the same time  
encryption goes in since it touches the same code paths.


I hope this helps clarify the Finder and XRLs.  Let me know if any of  
this is opaque or inadequately described.
Kind Regards
- Orion


On Mar 9, 2006, at 1:26 PM, Dave Roberts wrote:

> I have been looking at the XRL mechanism lately and had some  
> questions about how it works. I have read both the XRL  
> documentation on the XORP site as well as looked at the code, but a  
> bit of confirmation from those who know the code in detail would be  
> of assistance. Pointers to docs (RTFM) or particular code files  
> that should be investigated also appreciated.
>
> 1. I'm a bit unclear in how processes interact with the finder to  
> invoke XRLs. From what I have read, I think this is the process,  
> but any comments or corrections would be much appreciated. The  
> following assumes the STCP XRL transport. Let's also assume the  
> XRLs used in the "XORP Inter-Process Communication Library  
> Overview" document on the XORP site.
>    a. First, a client process makes a TCP connection to 127.0.0.1  
> (does it actually connect to "localhost", going through DNS  
> resolution on that, or just to the address directly) on port 19999  
> (Finder's well known port?).
>    b. Client sends a request packet to the Finder. The packet  
> containss the XRL. Say the XRL is "finder://fea/fti/0.1/add_route? 
> net:ipv4net=10.0.0.1/8&gateway:ipv4=192.150.187.1".
>    c. The Finder does the resolution and returns a response packet  
> to the client over the connection. The response packet contains the  
> same sequence number as in the request.
>    d. The response data is itself another complete encoded XRL,  
> this time resolved. Per the documentation, this would be something  
> like: "stcp://192.150.1.5:1992/fti/0.1/add_route? 
> net:ipv4net=10.0.0.1&gateway:ipv4=192.150.1.1".
>    e. The client parses this XRL and extracts the addressing  
> information.
>    f. The client opens a TCP connection (because of the "stcp"  
> scheme in the XRL) to 192.150.1.5 (won't this typically be  
> 127.0.0.1?), port 1992.
>    g. The client sends a request packet to the server (in this case  
> the FEA process). The request contains the encoded, resolved XRL.
>    f. The server sends back a response packet. This packet again  
> has matched sequence numbers to the request.
>    g. I'm not sure what the response contains? In this case, it  
> would seem that no response data is really required, though I  
> haven't looked at the add_route API to know for sure. If data is  
> required, is it returned in some sort of XRL form, or just as raw  
> XRL atoms?
>
> 2. How does a process register with the Finder? I know that it  
> probably opens a connection to the Finder and sends it one or more  
> XRLs that define the address and port on which it is listening, but  
> I'm not sure what those are. Are those XRLs sent on a special  
> connection to the finder, or just over the same one on which  
> resolution happens? Do XRLs invoked on the Finder itself go through  
> the two-hop resolution process?
>
> 3. How many outstanding XRL requests are allowed by a process at  
> one time? The IPC library seems to have some limits, but it isn't  
> clear what happens when those are exceeded.
>
> 4. The IPC Lib Overview document at one point says: "In addition to  
> handle XRL registrations and resolutions, the Finder is capable of  
> notifying XRL Targets about events it is aware of, like the birth  
> and death of other XRL Targets. The Finder exposes an XRL interface  
> for this purpose and is able to invoke XRLs on XRL Targets to  
> perform the notiÞcation. A special tunneling mechanism exists in  
> the communication protocol used to communicate with the Finder for  
> this purpose. The details of this communication will be expanded  
> upon later on [XXX in a later edit to this document]."
>
> Are there any more documents for this? Can somebody give an  
> overview of how this works?
>
> Thanks,
>
> -- Dave
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers



From dave@vyatta.com  Mon Mar 13 18:04:43 2006
From: dave@vyatta.com (Dave Roberts)
Date: Mon, 13 Mar 2006 10:04:43 -0800
Subject: [Xorp-hackers] XRL IPC questions
In-Reply-To: <55D3C465-8A33-4C34-B883-A77B152880F2@acm.org>
References: <44109D98.6070806@vyatta.com> <55D3C465-8A33-4C34-B883-A77B152880F2@acm.org>
Message-ID: <4415B43B.4040802@vyatta.com>

Orion, this was great. Thanks. A few follow-ups and clarifications below...

Orion Hodson wrote:
> You are on the right lines.  I've attempt to clarify a few points below 
> as I am responsible for this portion of the code and the lousy 
> documentation.

BTW, the docs were great as far as they went. I would just request more 
examples, particularly of the major processes in the system. The 
detailed questions I'm asking I would expect to find documented only in 
the code.

> 1. How do processes interact with the Finder?
> 
> The Finder is the resolver process.  There is one Finder per XORP router 
> instantiation.  The address and port of the Finder are configurable (via 
> XRL_FINDER_SERVER_ADDRESS and XRL_FINDER_SERVER_PORT environment 
> variables).  The default is 127.0.0.1/19999 and no DNS resolution is 
> done in the default case since a router can't depend on DNS to function.
> 
> When a process starts it connects to the Finder and informs it of all 
> the XRLs it supports and how they resolve into something the XRL library 
> can invoke - a transport type, an transport specific address, and a 
> string identifying the method.  For each XRL registered the Finder 
> provides the client with a strong name for the method supplied.  The 
> registering will only respond to invocations that use the  transport, 
> transport address, and the strong name.  The strong name is one piece in 
> making network attacks harder, otherwise it'd be trivial to craft XRLs 
> remotely and direct them at a XORP router.

Can you give an example here? I'm having trouble understand what this 
looks like in terms of XRLs/PDUs crossing between the two processes. In 
particular, it seems like the first connection to the finder is 
dedicated to doing resolutions, so when you say "it connects to the 
Finder and informs it of all the XRLs it supports," are you saying this 
happens on the first connection to 127.0.0.1/19999, or does the process 
invoke finder XRLs on a separate connection (an stcp://127.0.0.1:<finder 
port>/...) ?

Does that make sense?

If both functions, resolution and registration (and others, I suppose) 
share the 127.0.0.1/19999 connection, how does the finder discriminate 
between a client requesting a resolution and another XRL invocation 
specific to the Finder?

> Arguments are marshalled in XRLs according to the transport type.  Each 
> argument is represented by an XrlAtom.  For the most commonly used 
> transport, simple TCP (stcp), marshalling consists of rendering the atom 
> into a host-independent binary format.  Library support exists for 
> rendering to ASCII.  In the examples, we present the ASCII rendering 
> since it's easier to follow.

This is helpful, BTW.

> 2. How does a process register with the Finder?
> 
> The basic process is hopefully outlined in above.
> 
> One interesting point to note is that the Finder itself is an XRL 
> dispatcher just like other XORP processes.  When a process makes a 
> request to the Finder, such as registering an XRL, it sends the request 
> as an XRL to the Finder and the finder responds in the usual manner - an 
> error code plus result in the form of a list of XrlAtoms.

Got it.

> The transport for the Finder is handled as a special case as trying to 
> do otherwise made portions of the code hard to reason about.  The 
> protocol used to transport XRLs to the Finder is simply "finder" and 
> translates into a TCP connection to the known Finder host and port.
> 
> There is no strong-name mapping with Finder XRLs.  The method name sent 
> over the wire corresponds to code incable on the finder.  Otherwise we'd 
> have to deal with how to resolve Finder XRLs.

Having trouble parsing that. "incable" ?

> The first incarnation of the Finder used a totally disjoint 
> communication mechanism, but this went against the goal of 
> extensibility.  Having the Finder export XRL interfaces makes it easier 
> to extend.  We added the Finder Event Notifier interface pretty 
> trivially once we'd gotten the basic process-to-Finder communication 
> over XRLs.

Got it. So the resolution interface is really a special case, with 
everything else implemented as standard XRL interfaces, including 
registration and all other non-resolution functions of the Finder.

> 6. What about Finder security?
> 
> By default the Finder only accepts connections from the IP addresses 
> associated with the host it is running on, ie no external connections.  
> Additional addresses can be added at the command-line.
> 
> By dumping packets on the localhost (or local network for a distributed 
> XORP router) a hacker could determine the resolutions of XRLs and send 
> malicious messages to the XORP processes.  Adding encryption to the 
> Finder protocol would raise the bar to this attack.
> 
> The Finder XRL transport currently uses a naive packet encoding and it 
> is possible to crash the finder by connecting to it and sending it 
> junk.  This needs to be addressed and should happen at the same time 
> encryption goes in since it touches the same code paths.

This probably needs to be improved. Right now, the system relies on 
every on-box process being friendly. If an attacker can "get on the 
box", the whole system can be corrupted quite easily. In fact, with a 
simple client process, I can scan all open ports on the box and spew 
junk at them.

You probably want to end up with a Kerberos-like ticket granting scheme 
to verify that clients really are authorized to connect. In fact, why 
not just Kerberos itself? Seems like it does everything you want, 
including handle the distributed cases. It's probably more heavyweight 
than you'd like for the simple case, but it works and it has been tested 
for years for threats.

-- Dave


From marat@vyatta.com  Tue Mar 14 01:32:15 2006
From: marat@vyatta.com (Marat Nepomnyashy)
Date: Mon, 13 Mar 2006 17:32:15 -0800
Subject: [Xorp-hackers] Patch to add method SlaveConfigTreeNode::set_segname(...)
References: <200603110212.k2B2CqVT065904@possum.icir.org>
Message-ID: <021601c64707$20ebdf30$6402a8c0@CPQ16151965929>

OK Pavlin,

Since changing the multi-node name may cause sorting and other problems, I 
reworked the code to conventionally set the name in the constructor.  Thanks 
for evaluating the patch.

-- Marat

----- Original Message ----- 
From: "Pavlin Radoslavov" <pavlin@icir.org>
To: "Marat Nepomnyashy" <marat@vyatta.com>
Cc: "Pavlin Radoslavov" <pavlin@icir.org>; <xorp-hackers@xorp.org>
Sent: Friday, March 10, 2006 6:12 PM
Subject: Re: [Xorp-hackers] Patch to add method 
SlaveConfigTreeNode::set_segname(...)


>> Hi Pavlin,
>>
>> This method is intended for setting or changing the name of a newly 
>> created
>> multi-node.  After creating them, I either set the value if it is a 
>> regular
>> node, or the name if it is a multi-node.  Multi-nodes being added  that 
>> have
>> not yet been committed can also have their name changed without having to
>> recreate their child nodes.
>
> OK, this is the part I still don't understand.
> In general, the "segname" of a node is like a permanent name for a
> node that should not be modified after it is created. Otherwise,
> there could be various surprises. For example, we can have the
> multi-value nodes sorted (by their segname), and just changing the
> segname on the fly can be a disaster.
>
> It sounds like you create a multi-node and set its segname (say, IP
> address "1.1.1.1"). Then, before committing the configuration change
> the name of the multi-node is changed (say, "2.2.2.2"), and you want
> to just use "set_segname()" to change that node.
>
> To avoid the danger of segname renaming you should create a new
> multi-node "2.2.2.2" and then clone the "1.1.1.1" node's subtree to
> that node. For that purpose there is already method
> ConfigTreeNode::clone_subtree()
>
> Pavlin
>
>
>>
>> -- Marat
>>
>> ----- Original Message ----- 
>> From: "Pavlin Radoslavov" <pavlin@icir.org>
>> To: "Marat Nepomnyashy" <marat@vyatta.com>
>> Cc: "Pavlin Radoslavov" <pavlin@icir.org>; <xorp-hackers@xorp.org>
>> Sent: Thursday, March 09, 2006 6:02 PM
>> Subject: Re: [Xorp-hackers] Patch to add method
>> SlaveConfigTreeNode::set_segname(...)
>>
>>
>> >> Please consider the attached patch file for integration into XORP.  It
>> >> adds a convenience method SlaveConfigTreeNode::set_segname(...) to
>> >> /rtrmgr/slave_conf_tree_node.hh
>> >>
>> >> I'm using this method to set the name of a multi-node
>> >> SlaveConfigTreeNode after I create it.
>> >
>> > Marat,
>> >
>> > Why is the segname of a child allowed to change?
>> > It should be assigned when the node is created and shouldn't change
>> > after that.
>> > If the only time you need to set the segname is when you create the
>> > node, then it should be added as an argument to the appropriate
>> > constructor.
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers 


From oho@acm.org  Tue Mar 14 05:06:50 2006
From: oho@acm.org (Orion Hodson)
Date: Mon, 13 Mar 2006 21:06:50 -0800
Subject: [Xorp-hackers] XRL IPC questions
Message-ID: <B72EF8D3-E081-433F-9909-EC2E0ED11309@acm.org>

On Mar 13, 2006, at 10:04 AM, Dave Roberts wrote:

> Orion, this was great. Thanks. A few follow-ups and clarifications  
> below...
>
> Orion Hodson wrote:
>> You are on the right lines.  I've attempt to clarify a few points  
>> below as I am responsible for this portion of the code and the  
>> lousy documentation.
>
> BTW, the docs were great as far as they went. I would just request  
> more examples, particularly of the major processes in the system.  
> The detailed questions I'm asking I would expect to find documented  
> only in the code.
>
>> 1. How do processes interact with the Finder?
>> The Finder is the resolver process.  There is one Finder per XORP  
>> router instantiation.  The address and port of the Finder are  
>> configurable (via XRL_FINDER_SERVER_ADDRESS and  
>> XRL_FINDER_SERVER_PORT environment variables).  The default is  
>> 127.0.0.1/19999 and no DNS resolution is done in the default case  
>> since a router can't depend on DNS to function.
>> When a process starts it connects to the Finder and informs it of  
>> all the XRLs it supports and how they resolve into something the  
>> XRL library can invoke - a transport type, an transport specific  
>> address, and a string identifying the method.  For each XRL  
>> registered the Finder provides the client with a strong name for  
>> the method supplied.  The registering will only respond to  
>> invocations that use the  transport, transport address, and the  
>> strong name.  The strong name is one piece in making network  
>> attacks harder, otherwise it'd be trivial to craft XRLs remotely  
>> and direct them at a XORP router.
>
> Can you give an example here? I'm having trouble understand what  
> this looks like in terms of XRLs/PDUs crossing between the two  
> processes. In particular, it seems like the first connection to the  
> finder is dedicated to doing resolutions, so when you say "it  
> connects to the Finder and informs it of all the XRLs it supports,"  
> are you saying this happens on the first connection to  
> 127.0.0.1/19999, or does the process invoke finder XRLs on a  
> separate connection (an stcp://127.0.0.1:<finder port>/...) ?
>
> Does that make sense?
>
> If both functions, resolution and registration (and others, I  
> suppose) share the 127.0.0.1/19999 connection, how does the finder  
> discriminate between a client requesting a resolution and another  
> XRL invocation specific to the Finder?

The core XRL interface exported by the Finder is defined in xorp/xrl/ 
interfaces.xif.  If you look at it you'll see the add_xrl call that  
clients call to register XRLs and resolve_xrl to lookup XRL resolutions.

The connection to the Finder is a tcp connection, but it does not use  
the simple-tcp XRL protocol family that applications use.  This is  
because the XRL protocol families know things about their caller and  
the classes used by their caller have semantics that doesn't map  
cleanly into the Finder semantics.

An XRL request to the Finder is currently a 4 byte binary length  
indicator followed by an ascii message header and then the ASCII  
encoded XRL request.  It looks something like:

nnnn "Finder 0.2\n" "MsgType x\n" "SeqNo nnnn\n" ascii_xrl

Having the length field where it is and in binary is bit cruddy. This  
comes to pass because the length field is not known in the code path  
until the ascii header has been generated.  I'd forgotten the version  
number and other pieces were here since it's been a couple of years  
since I worked on the code.  You can find the code in libxipc/ 
finder_msgs.{hh,cc}.

If you want to see it in action you could run a packet sniffer, like  
ethereal, and inspect the packet contents.

>> The transport for the Finder is handled as a special case as  
>> trying to do otherwise made portions of the code hard to reason  
>> about.  The protocol used to transport XRLs to the Finder is  
>> simply "finder" and translates into a TCP connection to the known  
>> Finder host and port.
>> There is no strong-name mapping with Finder XRLs.  The method name  
>> sent over the wire corresponds to code incable on the finder.   
>> Otherwise we'd have to deal with how to resolve Finder XRLs.
>
> Having trouble parsing that. "incable" ?

Oops, 'invocable'.

>
>> The first incarnation of the Finder used a totally disjoint  
>> communication mechanism, but this went against the goal of  
>> extensibility.  Having the Finder export XRL interfaces makes it  
>> easier to extend.  We added the Finder Event Notifier interface  
>> pretty trivially once we'd gotten the basic process-to-Finder  
>> communication over XRLs.
>
> Got it. So the resolution interface is really a special case, with  
> everything else implemented as standard XRL interfaces, including  
> registration and all other non-resolution functions of the Finder.

Just to clarify again, there are no special cases - all interactions  
that processes have with the Finder are through XRL interfaces on the  
Finder.  The FinderClient (libxipc/finder_client.{hh,cc}) is the  
class in processes responsible for interacting with the Finder and  
all the calls it makes are through the same generated XRL sender code  
that the processes use to talk to each other.

>
>> 6. What about Finder security?
>> By default the Finder only accepts connections from the IP  
>> addresses associated with the host it is running on, ie no  
>> external connections.  Additional addresses can be added at the  
>> command-line.
>> By dumping packets on the localhost (or local network for a  
>> distributed XORP router) a hacker could determine the resolutions  
>> of XRLs and send malicious messages to the XORP processes.  Adding  
>> encryption to the Finder protocol would raise the bar to this attack.
>> The Finder XRL transport currently uses a naive packet encoding  
>> and it is possible to crash the finder by connecting to it and  
>> sending it junk.  This needs to be addressed and should happen at  
>> the same time encryption goes in since it touches the same code  
>> paths.
>
> This probably needs to be improved. Right now, the system relies on  
> every on-box process being friendly. If an attacker can "get on the  
> box", the whole system can be corrupted quite easily. In fact, with  
> a simple client process, I can scan all open ports on the box and  
> spew junk at them.
>
> You probably want to end up with a Kerberos-like ticket granting  
> scheme to verify that clients really are authorized to connect. In  
> fact, why not just Kerberos itself? Seems like it does everything  
> you want, including handle the distributed cases. It's probably  
> more heavyweight than you'd like for the simple case, but it works  
> and it has been tested for years for threats.

We definitely need to do something.  I'm not familiar enough with  
Kerberos to say whether it would be a good fit or not.  I suggested  
an approach to the core xorp devs using the OpenSSL crypto routines  
as the binaries already link against the library.  This is an area  
where someone could get involved with the project and make a really  
valuable contribution.

The protocols have validation routines that should hopefully deal  
with random spew connections from aotherwise trusted hosts.  There  
are unit tests in the regression suite that corrupt messages and try  
to test the validation paths, but there may well be holes.  BMS found  
a check missing in the Finder protocol for the field length, which  
when prodded could crash the Finder.

All the best
- Orion


From hasso@linux.ee  Tue Mar 14 19:09:38 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Tue, 14 Mar 2006 21:09:38 +0200
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: <200603110356.k2B3uDia067092@possum.icir.org>
References: <200603110356.k2B3uDia067092@possum.icir.org>
Message-ID: <200603142109.39054.hasso@linux.ee>

Pavlin Radoslavov wrote:
> This is different from the mechanism suggested by RFC 2082
> (Section 4.3).

Which is from 1997. And which is different from recommendations in RFC2328 
(appendix D) from 1998.

At first - time is passed since these times. Many points valid in these 
days are void nowadays. Take RFC2328 appendix B - Architectural 
Constants. They were meant to be really constants in '98, but I don't 
know any commercial OSPF implementation which have first three constants 
set to values defined there. They aren't even constants any more, but 
adaptive values.

And even if something is described in (recent) RFC, it doesn't mean that 
it is useful. Many times writers of standards put something into RFC's 
which turned to be void issue in practise or too complicate to implement 
or ... "Should" and "should not" are interpreted as "you can ignore this" 
anyway by implementers. No joking, btw, these are words from Juniper 
engineer.

Back to OSPF auth issues. Just start and end times valid for both 
generating and accepting are not suitable for OSPF. Think of hello timers 
set to 1s or even less (there are some implementations with thing called 
"fast timers"). Even slight difference in clocks would bring adjacencies 
down.

As far as I can see there is mostly two different ways the OSPF key switch 
mechanism is implemented in nowadays implementations (there are also 
implementations which allow only one key configured at time, but it 
shouldn't be option for Xorp).

IOS way: no any times associated with keys, if multiple keys are 
configured, multiple copies of every packet are sent over the interface - 
one with each configured keys.

Method is very simple, works well, but of course there is overhead in the 
moment of switch. With thousands of external prefixes it can be quite 
heavy traffic.

Junos way: one key active for sending OSPF packets, one timestamp can be 
configured per key - start generate time. Rules for choosing active key 
are simple: active is the key with most recent start-time in the past or 
if there isn't such key, then key with greatest ID without start-time. As 
you can see it's quite close to method described in D.3 RFC2328, except 
that only KeyStartGenerate is implemented. Accept time is always 
infinite.

In this way configuration and rules you should take into account are still 
kept quite simple (although it is more complicated than IOS way), but 
traffic overhead is avoided.

These are exactly the cases where implementers implemented minimal set of 
features required in practise without cluttering CLI with useless options 
which would make only shooting into foot easier. For Cisco engineers 
traffic overhead was acceptable, for Junos engineers it wasn't.

Learn from others ... Learn from existing implementations, see how they 
did things, try to think why they did it, what are pluses and minuses of 
their approaches. It helps to make Xorp better product.


-- 
Hasso Tepper

From dave@vyatta.com  Wed Mar 15 23:19:35 2006
From: dave@vyatta.com (Dave Roberts)
Date: Wed, 15 Mar 2006 15:19:35 -0800
Subject: [Xorp-hackers] UNH-IOL Test Results
Message-ID: <4418A107.5050901@vyatta.com>

I posted this to the Vyatta mailing lists a few minutes ago, but figured 
the XORP community would be interested as well. Note that this version 
of the OFR incorporated a relatively recent version of XORP, just prior 
to the recent XORP 1.2. We believe that some of the tests listed as 
failing in this report now pass with the most recent versions of XORP 
OSPF. Also note that officially, UNH-IOL did *not* test XORP, but rather 
a specific version of Vyatta's code and therefore no statements can or 
should be made about XORP's test results, since those don't officially 
exist. In spite of this, this is good news for the larger XORP community.

------------------

A couple of weeks ago, Vyatta took a version of the OFR code to the 
University of New Hampshire's InterOperability Lab (UNH-IOL). The lab 
does testing of various routing protocols for interoperability and 
conformance to the relevant protocol RFCs. Vyatta is a member of the 
UNH-IOL and will be sending future releases to the lab for additional 
testing.

In this round, we had UNH-IOL focus on the OSPF code.

The full test report can be found here:

http://www.vyatta.com/twiki/bin/view/Community/UnhTestResults

While the code did not pass 100% of all tests, this is a great result. 
In conjunction with our sponsorship of the XORP project, Vyatta will be 
working to increase that pass rate over time.

If you have any questions, please discuss on vyatta-users.

-- Dave

From pavlin@icir.org  Fri Mar 17 11:40:06 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 17 Mar 2006 03:40:06 -0800
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee>
 of "Tue, 14 Mar 2006 21:09:38 +0200." <200603142109.39054.hasso@linux.ee>
Message-ID: <200603171140.k2HBe6jk025907@possum.icir.org>

> Pavlin Radoslavov wrote:
> > This is different from the mechanism suggested by RFC 2082
> > (Section 4.3).
> 
> Which is from 1997. And which is different from recommendations in RFC2328 
> (appendix D) from 1998.
> 
> At first - time is passed since these times. Many points valid in these 
> days are void nowadays. Take RFC2328 appendix B - Architectural 
> Constants. They were meant to be really constants in '98, but I don't 
> know any commercial OSPF implementation which have first three constants 
> set to values defined there. They aren't even constants any more, but 
> adaptive values.
> 
> And even if something is described in (recent) RFC, it doesn't mean that 
> it is useful. Many times writers of standards put something into RFC's 
> which turned to be void issue in practise or too complicate to implement 
> or ... "Should" and "should not" are interpreted as "you can ignore this" 
> anyway by implementers. No joking, btw, these are words from Juniper 
> engineer.
> 
> Back to OSPF auth issues. Just start and end times valid for both 
> generating and accepting are not suitable for OSPF. Think of hello timers 
> set to 1s or even less (there are some implementations with thing called 
> "fast timers"). Even slight difference in clocks would bring adjacencies 
> down.
> 
> As far as I can see there is mostly two different ways the OSPF key switch 
> mechanism is implemented in nowadays implementations (there are also 
> implementations which allow only one key configured at time, but it 
> shouldn't be option for Xorp).
> 
> IOS way: no any times associated with keys, if multiple keys are 
> configured, multiple copies of every packet are sent over the interface - 
> one with each configured keys.
> 
> Method is very simple, works well, but of course there is overhead in the 
> moment of switch. With thousands of external prefixes it can be quite 
> heavy traffic.
> 
> Junos way: one key active for sending OSPF packets, one timestamp can be 
> configured per key - start generate time. Rules for choosing active key 
> are simple: active is the key with most recent start-time in the past or 
> if there isn't such key, then key with greatest ID without start-time. As 
> you can see it's quite close to method described in D.3 RFC2328, except 
> that only KeyStartGenerate is implemented. Accept time is always 
> infinite.
> 
> In this way configuration and rules you should take into account are still 
> kept quite simple (although it is more complicated than IOS way), but 
> traffic overhead is avoided.
> 
> These are exactly the cases where implementers implemented minimal set of 
> features required in practise without cluttering CLI with useless options 
> which would make only shooting into foot easier. For Cisco engineers 
> traffic overhead was acceptable, for Junos engineers it wasn't.

Let me describe what we have implemented so far and what we are
planning to add so you can see the tradeoffs we have chosen.

* RIP MD5
  There is optional start time and optional end time per key.
  If start time is missing from the configuration, it means "now";
  if end time is missing from the configuration, it means "forever".
  Only while a key is valid (i.e., within its start-end time
  period), a packet that matches that key is accepted.
  Also, if a key is valid, RIP transmits a copy of the packet with
  that authentication key.
  This means that RIP may transmit each packet more than once during
  key switchover: one copy per valid key.
  Opbiiously, it increases the control traffic during the
  switchover, but as you say it is relatively simple and robust
  solution.
  Though, the major reason we have chosen this solution is because
  it is within the lines of RFC 2082 "RIP-2 MD5 Authentication"
  Section 4.3.
  There are few things we need to fix in the current implementation,
  but the basic mechanism will remain same.

  Interestingly, in Juniper you cannot configure the RIP MD5 key ID.
  E.g., see Juniper's "Routing Protocols Configuration Guide"
  (Release 7.5) document, page 417, and the following email:

  http://www.atm.tut.fi/list-archive/juniper-nsp/msg03544.html

* OSPF MD5
  Indeed, RFC 2328 Section D describes a mechanism where there are
  four time constants associated with a key: KeyStartAccept,
  KeyStartGenerate, KeyStopGenerate, KeyStopAccept.
  And, yes, currently in XORP we have
  KeyStartAccept=KeyStartGenerate and KeyStopGenerate=KeyStopAccept.
  Furthermore, unlike the RIP MD5 implementation, we don't send
  multiple OSPF packets (one per each valid). Instead, we send a
  single packet (for one of the valid keys).
  As it is, we understand that this solution won't work when the
  clocks are not synchronized. And we didn't want to send multiple
  packets (one per key) as we do for RIP so due to time constraints
  we decided to come back to it and improve it later (after the 1.2
  release is out).

  The Cisco solution is not really acceptable for us, not only
  because of the extra traffic but also because it doesn't follow
  RFC 2328.
  The Juniper solution is admirable, because they conform to RFC
  2328 and at the same time have a nice solution to deal with clock
  differences: KeyStartGenerate=NOW, and
  KeyStopGenerate=KeyStopAccept=INFINITY.

  The downside of the Juniper solution is that you can't timeout the
  keys, but you have to remember to delete them when not needed
  anymore. Indeed, in your scenario of updating the keys for all
  your routers this is not an issue because you are closely
  monitoring everything.
  However, in other scenarios it is preferable to have expiration
  time for the keys. E.g., think about a scenario when you want to
  create a temporary time window (e.g., for testing purpose) for
  someone when they are allowed to be a part of your OSPF network,
  and after that you want to automatically revoke the MD5 key used
  for the experiment.

  To solve the clock differences problem, we need to make sure that
  KeyStartAccept < KeyStartGenerate and KeyStopGenerate < KeyStopAccept 
  We don't want to make all four time values configurable by the
  user, because this will make the configuration process too
  complicated.

  To solve the KeyStartAccess < KeyStartGenerate requirement we
  could use the Juniper solution by assuming that KeyStartAccept=NOW;
  however, this won't solve the KeyStopGenerate < KeyStopAccept
  requirement.

  Instead, we plan to use a new configurable time variable, say
  TimeSlack that is used to calculate KeyStartAccept and
  KeyStopAccept:

  KeyStartAccept = KeyStartGenerate - TimeSlack
  KeyStopAccept  = KeyStopGenerate + TimeSlack

  The TimeSlack variable will have a default value (say, 1800 secs),
  and will be configurable, but typically the user won't need to do
  anything about it. By doing so we:

  - Provide the additional functionality of having start-time and/or
    end-time.
  - Have a (configurable) solution for the clock syncronization
    problem.
  - Avoid the duplicated traffic.
  - Keep the MD5 key configuration relatively simple.

If folks have other suggestions/recommendations, now is the time to
speak before the above mechanism is implemented.

Pavlin

From kristian@juniks.net  Fri Mar 17 13:23:48 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Fri, 17 Mar 2006 14:23:48 +0100
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: <200603171140.k2HBe6jk025907@possum.icir.org>
References: <200603142109.39054.hasso@linux.ee> <200603171140.k2HBe6jk025907@possum.icir.org>
Message-ID: <20060317132348.GA30234@juniks.net>

On Fri, Mar 17, 2006 at 03:40:06AM -0800, Pavlin Radoslavov wrote:
> > Pavlin Radoslavov wrote:
> > > This is different from the mechanism suggested by RFC 2082
> > > (Section 4.3).
> > 
> > Which is from 1997. And which is different from recommendations in RFC2328 
> > (appendix D) from 1998.
> > 
> > At first - time is passed since these times. Many points valid in these 
> > days are void nowadays. Take RFC2328 appendix B - Architectural 
> > Constants. They were meant to be really constants in '98, but I don't 
> > know any commercial OSPF implementation which have first three constants 
> > set to values defined there. They aren't even constants any more, but 
> > adaptive values.
> > 
> > And even if something is described in (recent) RFC, it doesn't mean that 
> > it is useful. Many times writers of standards put something into RFC's 
> > which turned to be void issue in practise or too complicate to implement 
> > or ... "Should" and "should not" are interpreted as "you can ignore this" 
> > anyway by implementers. No joking, btw, these are words from Juniper 
> > engineer.
> > 
> > Back to OSPF auth issues. Just start and end times valid for both 
> > generating and accepting are not suitable for OSPF. Think of hello timers 
> > set to 1s or even less (there are some implementations with thing called 
> > "fast timers"). Even slight difference in clocks would bring adjacencies 
> > down.
> > 
> > As far as I can see there is mostly two different ways the OSPF key switch 
> > mechanism is implemented in nowadays implementations (there are also 
> > implementations which allow only one key configured at time, but it 
> > shouldn't be option for Xorp).
> > 
> > IOS way: no any times associated with keys, if multiple keys are 
> > configured, multiple copies of every packet are sent over the interface - 
> > one with each configured keys.
> > 
> > Method is very simple, works well, but of course there is overhead in the 
> > moment of switch. With thousands of external prefixes it can be quite 
> > heavy traffic.
> > 
> > Junos way: one key active for sending OSPF packets, one timestamp can be 
> > configured per key - start generate time. Rules for choosing active key 
> > are simple: active is the key with most recent start-time in the past or 
> > if there isn't such key, then key with greatest ID without start-time. As 
> > you can see it's quite close to method described in D.3 RFC2328, except 
> > that only KeyStartGenerate is implemented. Accept time is always 
> > infinite.
> > 
> > In this way configuration and rules you should take into account are still 
> > kept quite simple (although it is more complicated than IOS way), but 
> > traffic overhead is avoided.
> > 
> > These are exactly the cases where implementers implemented minimal set of 
> > features required in practise without cluttering CLI with useless options 
> > which would make only shooting into foot easier. For Cisco engineers 
> > traffic overhead was acceptable, for Junos engineers it wasn't.
> 
> Let me describe what we have implemented so far and what we are
> planning to add so you can see the tradeoffs we have chosen.
> 
> * RIP MD5
>   There is optional start time and optional end time per key.
>   If start time is missing from the configuration, it means "now";
>   if end time is missing from the configuration, it means "forever".
>   Only while a key is valid (i.e., within its start-end time
>   period), a packet that matches that key is accepted.
>   Also, if a key is valid, RIP transmits a copy of the packet with
>   that authentication key.
>   This means that RIP may transmit each packet more than once during
>   key switchover: one copy per valid key.
>   Opbiiously, it increases the control traffic during the
>   switchover, but as you say it is relatively simple and robust
>   solution.
>   Though, the major reason we have chosen this solution is because
>   it is within the lines of RFC 2082 "RIP-2 MD5 Authentication"
>   Section 4.3.
>   There are few things we need to fix in the current implementation,
>   but the basic mechanism will remain same.
> 
>   Interestingly, in Juniper you cannot configure the RIP MD5 key ID.
>   E.g., see Juniper's "Routing Protocols Configuration Guide"
>   (Release 7.5) document, page 417, and the following email:
> 
>   http://www.atm.tut.fi/list-archive/juniper-nsp/msg03544.html
> 
> * OSPF MD5
>   Indeed, RFC 2328 Section D describes a mechanism where there are
>   four time constants associated with a key: KeyStartAccept,
>   KeyStartGenerate, KeyStopGenerate, KeyStopAccept.
>   And, yes, currently in XORP we have
>   KeyStartAccept=KeyStartGenerate and KeyStopGenerate=KeyStopAccept.
>   Furthermore, unlike the RIP MD5 implementation, we don't send
>   multiple OSPF packets (one per each valid). Instead, we send a
>   single packet (for one of the valid keys).
>   As it is, we understand that this solution won't work when the
>   clocks are not synchronized. And we didn't want to send multiple
>   packets (one per key) as we do for RIP so due to time constraints
>   we decided to come back to it and improve it later (after the 1.2
>   release is out).
> 
>   The Cisco solution is not really acceptable for us, not only
>   because of the extra traffic but also because it doesn't follow
>   RFC 2328.
>   The Juniper solution is admirable, because they conform to RFC
>   2328 and at the same time have a nice solution to deal with clock
>   differences: KeyStartGenerate=NOW, and
>   KeyStopGenerate=KeyStopAccept=INFINITY.
> 
>   The downside of the Juniper solution is that you can't timeout the
>   keys, but you have to remember to delete them when not needed
>   anymore. Indeed, in your scenario of updating the keys for all
>   your routers this is not an issue because you are closely
>   monitoring everything.
>   However, in other scenarios it is preferable to have expiration
>   time for the keys. E.g., think about a scenario when you want to
>   create a temporary time window (e.g., for testing purpose) for
>   someone when they are allowed to be a part of your OSPF network,
>   and after that you want to automatically revoke the MD5 key used
>   for the experiment.
> 
>   To solve the clock differences problem, we need to make sure that
>   KeyStartAccept < KeyStartGenerate and KeyStopGenerate < KeyStopAccept 
>   We don't want to make all four time values configurable by the
>   user, because this will make the configuration process too
>   complicated.
> 
>   To solve the KeyStartAccess < KeyStartGenerate requirement we
>   could use the Juniper solution by assuming that KeyStartAccept=NOW;
>   however, this won't solve the KeyStopGenerate < KeyStopAccept
>   requirement.
> 
>   Instead, we plan to use a new configurable time variable, say
>   TimeSlack that is used to calculate KeyStartAccept and
>   KeyStopAccept:
> 
>   KeyStartAccept = KeyStartGenerate - TimeSlack
>   KeyStopAccept  = KeyStopGenerate + TimeSlack
> 
>   The TimeSlack variable will have a default value (say, 1800 secs),
>   and will be configurable, but typically the user won't need to do
>   anything about it. By doing so we:
> 
>   - Provide the additional functionality of having start-time and/or
>     end-time.
>   - Have a (configurable) solution for the clock syncronization
>     problem.
>   - Avoid the duplicated traffic.
>   - Keep the MD5 key configuration relatively simple.
> 
> If folks have other suggestions/recommendations, now is the time to
> speak before the above mechanism is implemented.
Aye! I like the sound of it. I'm all for.

Regards,
Kristian

From mleech@nortel.com  Fri Mar 17 16:08:48 2006
From: mleech@nortel.com (Marcus Leech)
Date: Fri, 17 Mar 2006 11:08:48 -0500
Subject: [Xorp-hackers] Speaking of security
Message-ID: <441ADF10.4070602@nortel.com>

Does anyone know if there are plans to put TCP MD5 signatures into the 
Linux kernel, so that
  BGP can use this feature?

Also, what are the plans for integrating routing security mechanisms 
like S-BGP, soBGP, or psBGP?

-- 
Marcus Leech                            Mail:   Dept 1A12, M/S: 04352P16
Security Standards Advisor        Phone: (ESN) 393-9145  +1 613 763 9145
Strategic Standards
Nortel Networks                          mleech@nortel.com



From kristian@juniks.net  Sun Mar 19 19:52:34 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Sun, 19 Mar 2006 20:52:34 +0100
Subject: [Xorp-hackers] Old bug entries
Message-ID: <20060319195234.GA4227@juniks.net>

Hi

could someone please look through the Bugzilla
database. There are a few bug entries for which
there are patches that have not been commited to
CVS. Neither has there been given any reason to
why they have not been commited. Would be nice to
clean it up a bit :)

Regards,
Kristian

From kristian@juniks.net  Sun Mar 19 20:06:21 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Sun, 19 Mar 2006 21:06:21 +0100
Subject: [Xorp-hackers] BG 172
Message-ID: <20060319200620.GB4227@juniks.net>

It's been awhile since Hassos entry on this bug
so I assume noone is actively working on this. 
As the XORP developers so far have not recognized
this as a bug I wonder how we should proceed?

Best regards,
   Kristian.

From M.Handley@cs.ucl.ac.uk  Sun Mar 19 20:42:12 2006
From: M.Handley@cs.ucl.ac.uk (Mark Handley)
Date: Sun, 19 Mar 2006 20:42:12 +0000
Subject: [Xorp-hackers] BG 172
In-Reply-To: <20060319200620.GB4227@juniks.net>
References: <20060319200620.GB4227@juniks.net>
Message-ID: <84a612dd0603191242p1c670ddif337df6f2bdea719@mail.gmail.com>

On 3/19/06, Kristian Larsson <kristian@juniks.net> wrote:
> It's been awhile since Hassos entry on this bug
> so I assume noone is actively working on this.
> As the XORP developers so far have not recognized
> this as a bug I wonder how we should proceed?

There are a lot of different issues in that thread.  The first message
may be indicating a bug (I'm not sure - it's hard to tell), but the
others are all discussing a change of UI, which isn't a bug but rather
it's a feature request :-)

>From a coding point of view, it isn't terribly hard to remove the
create command and perform the same functionality with the set
command.  But I'm not sure we every reached a conclusion on the
desired UI, so I'd like to re-open the discussion.

The reason for the create command was to make it obvious to the user
the difference between creating a node where there can be many (such
as creating peers in BGP, or adding addresses to an interface), and
setting a parameter (when it's only possible to have one value, such
as the holdtime on a particular peering).  This was supposed to be
less confusing to the user - the two behaviours are fundamentally
different, and using a single command means the user can't tell from
the command which behaviour will occur.

With hindsight though, it's not clear to me if it is in fact less
confusing.  But it's hard to tell, because my worldview is distorted
by using XORP, and other's worldviews are clearly distorted by using
Juniper boxes.

So, what do you think is easiest for the user?  That's what matters
most.  If we can agree what the simplest and least confusing UI is, we
will code it.

 - Mark


From kristian@juniks.net  Sun Mar 19 23:24:18 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Mon, 20 Mar 2006 00:24:18 +0100
Subject: [Xorp-hackers] BG 172
In-Reply-To: <84a612dd0603191242p1c670ddif337df6f2bdea719@mail.gmail.com>
References: <20060319200620.GB4227@juniks.net> <84a612dd0603191242p1c670ddif337df6f2bdea719@mail.gmail.com>
Message-ID: <20060319232417.GC4227@juniks.net>

On Sun, Mar 19, 2006 at 08:42:12PM +0000, Mark Handley wrote:
> On 3/19/06, Kristian Larsson <kristian@juniks.net> wrote:
> > It's been awhile since Hassos entry on this bug
> > so I assume noone is actively working on this.
> > As the XORP developers so far have not recognized
> > this as a bug I wonder how we should proceed?
> 
> There are a lot of different issues in that thread.  The first message
> may be indicating a bug (I'm not sure - it's hard to tell), but the
> others are all discussing a change of UI, which isn't a bug but rather
> it's a feature request :-)
Score! ;)

> From a coding point of view, it isn't terribly hard to remove the
> create command and perform the same functionality with the set
> command.  But I'm not sure we every reached a conclusion on the
> desired UI, so I'd like to re-open the discussion.
> 
> The reason for the create command was to make it obvious to the user
> the difference between creating a node where there can be many (such
> as creating peers in BGP, or adding addresses to an interface), and
> setting a parameter (when it's only possible to have one value, such
> as the holdtime on a particular peering).  This was supposed to be
> less confusing to the user - the two behaviours are fundamentally
> different, and using a single command means the user can't tell from
> the command which behaviour will occur.
I agree that this is a 'beautiful' solution from a
design perspective but we should prioritize
usability and not design aestethics.

> 
> With hindsight though, it's not clear to me if it is in fact less
> confusing.  But it's hard to tell, because my worldview is distorted
> by using XORP, and other's worldviews are clearly distorted by using
> Juniper boxes.
True although I'd say my mind is mostly distorted
by Ciscos IOS with all it's irradical design
decisions (peer-groups comes to mind). 

> So, what do you think is easiest for the user?  That's what matters
> most.  If we can agree what the simplest and least confusing UI is, we
> will code it.
I'm all for the "JunOS way". Ie, no create
command, but you probably already know my opinion
by now :)

Regards,
  Kristian.


From dave@vyatta.com  Mon Mar 20 03:34:07 2006
From: dave@vyatta.com (Dave Roberts)
Date: Sun, 19 Mar 2006 19:34:07 -0800 (PST)
Subject: [Xorp-hackers] BG 172
Message-ID: <7167270.7141142825647626.JavaMail.root@mail.vyatta.com>

The use of create vs. set is confusing to just about everybody I have talked to who has worked with the system. It's never quite clear when one should use one vs. the other, particularly with things like default parameters. Also, once you create things, you then have to use set, not create to set them again. It's generally confusing.

+1 to remove create and just go with set/delete.

-- Dave

----- Mark Handley <M.Handley@cs.ucl.ac.uk> wrote:
> On 3/19/06, Kristian Larsson <kristian@juniks.net> wrote:
> > It's been awhile since Hassos entry on this bug
> > so I assume noone is actively working on this.
> > As the XORP developers so far have not recognized
> > this as a bug I wonder how we should proceed?
> 
> There are a lot of different issues in that thread.  The first
> message
> may be indicating a bug (I'm not sure - it's hard to tell), but the
> others are all discussing a change of UI, which isn't a bug but
> rather
> it's a feature request :-)
> 
> From a coding point of view, it isn't terribly hard to remove the
> create command and perform the same functionality with the set
> command.  But I'm not sure we every reached a conclusion on the
> desired UI, so I'd like to re-open the discussion.
> 
> The reason for the create command was to make it obvious to the user
> the difference between creating a node where there can be many (such
> as creating peers in BGP, or adding addresses to an interface), and
> setting a parameter (when it's only possible to have one value, such
> as the holdtime on a particular peering).  This was supposed to be
> less confusing to the user - the two behaviours are fundamentally
> different, and using a single command means the user can't tell from
> the command which behaviour will occur.
> 
> With hindsight though, it's not clear to me if it is in fact less
> confusing.  But it's hard to tell, because my worldview is distorted
> by using XORP, and other's worldviews are clearly distorted by using
> Juniper boxes.
> 
> So, what do you think is easiest for the user?  That's what matters
> most.  If we can agree what the simplest and least confusing UI is,
> we
> will code it.
> 
>  - Mark
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From hasso@linux.ee  Mon Mar 20 09:48:36 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Mon, 20 Mar 2006 11:48:36 +0200
Subject: [Xorp-hackers] BG 172
In-Reply-To: <84a612dd0603191242p1c670ddif337df6f2bdea719@mail.gmail.com>
References: <20060319200620.GB4227@juniks.net> <84a612dd0603191242p1c670ddif337df6f2bdea719@mail.gmail.com>
Message-ID: <200603201148.36903.hasso@linux.ee>

Mark Handley wrote:
> The reason for the create command was to make it obvious to the user
> the difference between creating a node where there can be many (such
> as creating peers in BGP, or adding addresses to an interface), and
> setting a parameter (when it's only possible to have one value, such
> as the holdtime on a particular peering).

You are assuming here that user should know exact structure of all 
configuration statements which is insane.

> This was supposed to be less confusing to the user - the two behaviours 
> are fundamentally different, and using a single command means the user 
> can't tell from the command which behaviour will occur.

While entering new statements into configuration users don't care how the 
result will appear in configuration - whether command ends with 
intermediate or leaf node. They don't need that knowledge. They need this 
knowledge while working with existing configuration and then they already 
see how configuration structure with "show" command. 

> With hindsight though, it's not clear to me if it is in fact less
> confusing.  But it's hard to tell, because my worldview is distorted
> by using XORP, and other's worldviews are clearly distorted by using
> Juniper boxes.

It's Junos vs. Xorp topic, it's general usability issue. There are two 
ways to start entering configuration command in Xorp - create vs. set. I 
don't know any other CLI behaving this way. User don't know exactly how 
configuration is built up. He presses tab and discovers logical path to 
configuration he/she wants. And using both create and set means a lot of 
more typing for user.

"I want to default LSA into ospf area with metric 10 , lets find out ... 
"set ?" ... "protocols " ... "ospf " ... "area 0.0.0.10 " ... hmmm, no 
any word about default ... argh, I have to create it before. "create 
protocols ospf area 0.0.0.10 default-lsa", "set protocols ospf area 
0.0.0.10 default-lsa metric 10" etc."

In all other CLI's there is only one path - to enter one configuration 
statement you don't have to go back to the beginning of the entering 
statement.

All Xorp users (testers actually) I know at the moment (including me) just 
use create command and take two issues as annoying bugs - difference from 
Junos cli and that create doesn't complete existing intermediate node 
names.


-- 
Hasso Tepper

From hasso@linux.ee  Mon Mar 20 11:30:18 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Mon, 20 Mar 2006 13:30:18 +0200
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: <200603171140.k2HBe6jk025907@possum.icir.org>
References: <200603171140.k2HBe6jk025907@possum.icir.org>
Message-ID: <200603201330.18966.hasso@linux.ee>

Pavlin Radoslavov wrote:
>   Interestingly, in Juniper you cannot configure the RIP MD5 key ID.
>   E.g., see Juniper's "Routing Protocols Configuration Guide"
>   (Release 7.5) document, page 417, and the following email:
>
>   http://www.atm.tut.fi/list-archive/juniper-nsp/msg03544.html

It just isn't in very high place in the list of their priorities probably. 
Who uses RIP nowadays at all ;)? Especially in the routers with Junos. 

>   The Cisco solution is not really acceptable for us, not only
>   because of the extra traffic but also because it doesn't follow
>   RFC 2328.

This kind of arguments are irrelevant here. I already brought examples 
that even MUST part of RFC are ignored. Interoperability matters, that's 
all. As long as you don't create interoperability problems, you are OK. 
And note that this kind of info like key management isn't in the 
standards nowadays at all (with sentence "it isn't in the scope of this 
document") or is in separate document with note "best practice".

OSPFv2 RFC is really old, there is a lot of differences with nowadays 
implementations, but as there is no real interoperability problems yet, 
nobody will update to conform latest changes and best practices.

>   However, in other scenarios it is preferable to have expiration
>   time for the keys. E.g., think about a scenario when you want to
>   create a temporary time window (e.g., for testing purpose) for
>   someone when they are allowed to be a part of your OSPF network,
>   and after that you want to automatically revoke the MD5 key used
>   for the experiment.

I don't see the any need for such behaviour. I already said that I take 
this kind of automatic dangerous.

> Instead, we plan to use a new configurable time variable, say
> TimeSlack that is used to calculate KeyStartAccept and
> KeyStopAccept:
>
> KeyStartAccept = KeyStartGenerate - TimeSlack
> KeyStopAccept  = KeyStopGenerate + TimeSlack
>
> The TimeSlack variable will have a default value (say, 1800 secs),
> and will be configurable, but typically the user won't need to do
> anything about it.

I'm not so sure. So, instead of four selfdescriptive statements there will 
be three relevant statements in the configuration, but one of them will 
not be selfdescriptive in any way - it needs exact knowledge how this 
stuff works together.

But I have no better ideas either how to avoid "shooting into foot" 
situations and provide end-time as well.

Btw, this reminds me the question - there is some "%help: long" statements 
in templates. How to use them? Or isn't this implemented yet?


regards,

-- 
Hasso Tepper

From hasso@linux.ee  Mon Mar 20 12:41:49 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Mon, 20 Mar 2006 14:41:49 +0200
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: <20060319195234.GA4227@juniks.net>
References: <20060319195234.GA4227@juniks.net>
Message-ID: <200603201441.49957.hasso@linux.ee>

Kristian Larsson wrote:
> could someone please look through the Bugzilla database. There are a few 
> bug entries for which there are patches that have not been commited to
> CVS. Neither has there been given any reason to why they have not been 
> commited. Would be nice to clean it up a bit :)

No offence, but some patches are in the bugzilla really too long without 
any feedback. I know, I know ... we all have our priorities and just 
don't find time for all stuff we'd like to do, but ...

>From my position it gets harder with every new patch to maintain local 
branch and I'd like to see patches go in or rejected and thrown away. And 
if there is any problem with patches I, as author, can help with, please 
say how. If patch is just crap, wrong, doesn't meet coding standards, you 
don't agree with it at all or whatever, please say so. I fully open to 
discussion regarding my patches.

I meant especially patches in bugzilla entries #463 and #464. But also 
#372 and #516. And I'd be really glad if someone can take a look at #574 
as well, some of these are really obvious problems.


with my best wishes,

-- 
Hasso Tepper


From mhorn@vyatta.com  Mon Mar 20 15:38:24 2006
From: mhorn@vyatta.com (Mike Horn)
Date: Mon, 20 Mar 2006 07:38:24 -0800 (PST)
Subject: [Xorp-hackers] BG 172
Message-ID: <9280364.7211142869104285.JavaMail.root@mail.vyatta.com>

Another vote for removing "create" and having "set" and "edit" create the intermediary nodes.  I can understand the initial logic in having the set vs. create, but I think it causes more confusion than it eliminates.

-mike


----- Original Message -----
From: Hasso Tepper <hasso@linux.ee>
To: xorp-hackers@icir.org
Sent: Monday, March 20, 2006 2:48:36 AM GMT-0700
Subject: Re: [Xorp-hackers] BG 172

Mark Handley wrote:
> The reason for the create command was to make it obvious to the user
> the difference between creating a node where there can be many (such
> as creating peers in BGP, or adding addresses to an interface), and
> setting a parameter (when it's only possible to have one value, such
> as the holdtime on a particular peering).

You are assuming here that user should know exact structure of all 
configuration statements which is insane.

> This was supposed to be less confusing to the user - the two behaviours 
> are fundamentally different, and using a single command means the user 
> can't tell from the command which behaviour will occur.

While entering new statements into configuration users don't care how the 
result will appear in configuration - whether command ends with 
intermediate or leaf node. They don't need that knowledge. They need this 
knowledge while working with existing configuration and then they already 
see how configuration structure with "show" command. 

> With hindsight though, it's not clear to me if it is in fact less
> confusing.  But it's hard to tell, because my worldview is distorted
> by using XORP, and other's worldviews are clearly distorted by using
> Juniper boxes.

It's Junos vs. Xorp topic, it's general usability issue. There are two 
ways to start entering configuration command in Xorp - create vs. set. I 
don't know any other CLI behaving this way. User don't know exactly how 
configuration is built up. He presses tab and discovers logical path to 
configuration he/she wants. And using both create and set means a lot of 
more typing for user.

"I want to default LSA into ospf area with metric 10 , lets find out ... 
"set ?" ... "protocols " ... "ospf " ... "area 0.0.0.10 " ... hmmm, no 
any word about default ... argh, I have to create it before. "create 
protocols ospf area 0.0.0.10 default-lsa", "set protocols ospf area 
0.0.0.10 default-lsa metric 10" etc."

In all other CLI's there is only one path - to enter one configuration 
statement you don't have to go back to the beginning of the entering 
statement.

All Xorp users (testers actually) I know at the moment (including me) just 
use create command and take two issues as annoying bugs - difference from 
Junos cli and that create doesn't complete existing intermediate node 
names.


-- 
Hasso Tepper
_______________________________________________
Xorp-hackers mailing list
Xorp-hackers@icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

From hasso@linux.ee  Mon Mar 20 16:50:53 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Mon, 20 Mar 2006 18:50:53 +0200
Subject: [Xorp-hackers] BG 172
In-Reply-To: <441ECC31.9050404@cs.ucla.edu>
References: <20060319200620.GB4227@juniks.net> <200603201148.36903.hasso@linux.ee> <441ECC31.9050404@cs.ucla.edu>
Message-ID: <200603201850.53289.hasso@linux.ee>

Eddie Kohler wrote:
> Sounds like there are pretty convincing reasons to drop create (or,
> more precisely, make it a synonym for set).

As I commented already in bugzilla #172, create behaves already almost as 
needed, it just doesn't complete existing intermediate node names 
(interface names, bgp peers, ospf areas etc.). Make it complete them, 
remove current set and rename create to set.

> Mark's argument about the differences in semantics is not as convincing
> now, although it seemed like it was a good idea at the time.  Question,
> though: It seems like there is no case where "set X Y Z" and "create X
> Y Z" are both valid and have different semantics.  True/false?  If
> true, that's another reason to get rid of create.

True. Set is able to change only values of non-unique leaf nodes and 
create behaves the same way with these - changes value.


-- 
Hasso Tepper

From kohler@cs.ucla.edu  Mon Mar 20 15:37:21 2006
From: kohler@cs.ucla.edu (Eddie Kohler)
Date: Mon, 20 Mar 2006 07:37:21 -0800
Subject: [Xorp-hackers] BG 172
In-Reply-To: <200603201148.36903.hasso@linux.ee>
References: <20060319200620.GB4227@juniks.net> <84a612dd0603191242p1c670ddif337df6f2bdea719@mail.gmail.com> <200603201148.36903.hasso@linux.ee>
Message-ID: <441ECC31.9050404@cs.ucla.edu>

Sounds like there are pretty convincing reasons to drop create (or, more 
precisely, make it a synonym for set).

Mark's argument about the differences in semantics is not as convincing now, 
although it seemed like it was a good idea at the time.  Question, though: It 
seems like there is no case where "set X Y Z" and "create X Y Z" are both 
valid and have different semantics.  True/false?  If true, that's another 
reason to get rid of create.

You could get Mark's UI benefit by printing a message when the create behavior 
is triggered, something like "created ospf area 0.0.0.10".  You could turn the 
message off of course.

2c
Eddie


Hasso Tepper wrote:
> Mark Handley wrote:
> 
>>The reason for the create command was to make it obvious to the user
>>the difference between creating a node where there can be many (such
>>as creating peers in BGP, or adding addresses to an interface), and
>>setting a parameter (when it's only possible to have one value, such
>>as the holdtime on a particular peering).
> 
> 
> You are assuming here that user should know exact structure of all 
> configuration statements which is insane.
> 
> 
>>This was supposed to be less confusing to the user - the two behaviours 
>>are fundamentally different, and using a single command means the user 
>>can't tell from the command which behaviour will occur.
> 
> 
> While entering new statements into configuration users don't care how the 
> result will appear in configuration - whether command ends with 
> intermediate or leaf node. They don't need that knowledge. They need this 
> knowledge while working with existing configuration and then they already 
> see how configuration structure with "show" command. 
> 
> 
>>With hindsight though, it's not clear to me if it is in fact less
>>confusing.  But it's hard to tell, because my worldview is distorted
>>by using XORP, and other's worldviews are clearly distorted by using
>>Juniper boxes.
> 
> 
> It's Junos vs. Xorp topic, it's general usability issue. There are two 
> ways to start entering configuration command in Xorp - create vs. set. I 
> don't know any other CLI behaving this way. User don't know exactly how 
> configuration is built up. He presses tab and discovers logical path to 
> configuration he/she wants. And using both create and set means a lot of 
> more typing for user.
> 
> "I want to default LSA into ospf area with metric 10 , lets find out ... 
> "set ?" ... "protocols " ... "ospf " ... "area 0.0.0.10 " ... hmmm, no 
> any word about default ... argh, I have to create it before. "create 
> protocols ospf area 0.0.0.10 default-lsa", "set protocols ospf area 
> 0.0.0.10 default-lsa metric 10" etc."
> 
> In all other CLI's there is only one path - to enter one configuration 
> statement you don't have to go back to the beginning of the entering 
> statement.
> 
> All Xorp users (testers actually) I know at the moment (including me) just 
> use create command and take two issues as annoying bugs - difference from 
> Junos cli and that create doesn't complete existing intermediate node 
> names.
> 
> 

From atanu@ICSI.Berkeley.EDU  Mon Mar 20 20:57:18 2006
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 20 Mar 2006 12:57:18 -0800
Subject: [Xorp-hackers] Speaking of security
In-Reply-To: Message from "Marcus Leech" <mleech@nortel.com>
 of "Fri, 17 Mar 2006 11:08:48 EST." <441ADF10.4070602@nortel.com>
Message-ID: <12796.1142888238@tigger.icir.org>

    Marcus> Also, what are the plans for integrating routing security
    Marcus> mechanisms like S-BGP, soBGP, or psBGP?

We don't have the resources to implement all BGP security derivatives,
if one scheme wins out we will probably implement it.

We hope that our BGP implementation is extensible enough that others can
implement these or other ideas.

For example:
<www.cs.ucl.ac.uk/staff/M.Handley/papers/hlpsigcomm.pdf> 

       Atanu.

From pavlin@icir.org  Mon Mar 20 22:55:20 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 20 Mar 2006 14:55:20 -0800
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: Message from Kristian Larsson <kristian@juniks.net>
 of "Sun, 19 Mar 2006 20:52:34 +0100." <20060319195234.GA4227@juniks.net>
Message-ID: <200603202255.k2KMtKSu033600@possum.icir.org>

> could someone please look through the Bugzilla
> database. There are a few bug entries for which
> there are patches that have not been commited to
> CVS. Neither has there been given any reason to
> why they have not been commited. Would be nice to
> clean it up a bit :)

We are looking at these, but usually things take time to get it done
right. And, yes, even if there is a patch for a solution we still
need to double-check it before applying the patch.

Though, yes, we should change the status of an entry to ASSIGNED (or
at least put some comment) when possible so the person reporting the
bug is not left wondering about it.

Pavlin

From pavlin@icir.org  Mon Mar 20 23:04:39 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 20 Mar 2006 15:04:39 -0800
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee>
 of "Mon, 20 Mar 2006 14:41:49 +0200." <200603201441.49957.hasso@linux.ee>
Message-ID: <200603202304.k2KN4di6033659@possum.icir.org>

> Kristian Larsson wrote:
> > could someone please look through the Bugzilla database. There are a few 
> > bug entries for which there are patches that have not been commited to
> > CVS. Neither has there been given any reason to why they have not been 
> > commited. Would be nice to clean it up a bit :)
> 
> No offence, but some patches are in the bugzilla really too long without 
> any feedback. I know, I know ... we all have our priorities and just 
> don't find time for all stuff we'd like to do, but ...
> 
> >From my position it gets harder with every new patch to maintain local 
> branch and I'd like to see patches go in or rejected and thrown away. And 
> if there is any problem with patches I, as author, can help with, please 
> say how. If patch is just crap, wrong, doesn't meet coding standards, you 
> don't agree with it at all or whatever, please say so. I fully open to 
> discussion regarding my patches.
> 
> I meant especially patches in bugzilla entries #463 and #464. But also 
> #372 and #516. And I'd be really glad if someone can take a look at #574 
> as well, some of these are really obvious problems.

I understand, and I apologize for letting some things not flow as smooth
as everyone would like.

With regard to #463 and #464 I started working on them before the
release, but in the process of integrating the patch I came across
a section that needed more careful testing. Such testing was going
to be time-consuming and we were getting too close to the release to
take the risk to apply the patch so at the end I decided to postpone
the integration after the release. Though, yes, I should have added
at least a note to the bugzilla entry about this.

Right now it is on my TODO list right after the MD5 fix and #574,
because I also want to get rid of my local branch :)

Pavlin

From pavlin@icir.org  Tue Mar 21 01:18:53 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 20 Mar 2006 17:18:53 -0800
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee>
 of "Mon, 20 Mar 2006 13:30:18 +0200." <200603201330.18966.hasso@linux.ee>
Message-ID: <200603210118.k2L1Iris035157@possum.icir.org>

> >   Interestingly, in Juniper you cannot configure the RIP MD5 key ID.
> >   E.g., see Juniper's "Routing Protocols Configuration Guide"
> >   (Release 7.5) document, page 417, and the following email:
> >
> >   http://www.atm.tut.fi/list-archive/juniper-nsp/msg03544.html
> 
> It just isn't in very high place in the list of their priorities probably. 
> Who uses RIP nowadays at all ;)? Especially in the routers with Junos. 

I hope you are not going to recommend us to remove our RIP
implementation ;)

> >   The Cisco solution is not really acceptable for us, not only
> >   because of the extra traffic but also because it doesn't follow
> >   RFC 2328.
> 
> This kind of arguments are irrelevant here. I already brought examples 
> that even MUST part of RFC are ignored. Interoperability matters, that's 
> all. As long as you don't create interoperability problems, you are OK. 
> And note that this kind of info like key management isn't in the 
> standards nowadays at all (with sentence "it isn't in the scope of this 
> document") or is in separate document with note "best practice".

The example you gave about RFC 2328 Appendix B is about changing
protocol parameters. This is typically allowed when
implementing/configuring a protocol.
The Cisco's change I am referring to is about a not-so elegant
deviation from the spec.

> >   However, in other scenarios it is preferable to have expiration
> >   time for the keys. E.g., think about a scenario when you want to
> >   create a temporary time window (e.g., for testing purpose) for
> >   someone when they are allowed to be a part of your OSPF network,
> >   and after that you want to automatically revoke the MD5 key used
> >   for the experiment.
> 
> I don't see the any need for such behaviour. I already said that I take 
> this kind of automatic dangerous.

I understand that in your production environment (and probably
everybody else's) you want strict control.
With our solution we don't take this control away from you.

You could always set the start-time to the value you want and ignore
end-time and the new TimeSlack: the end time of the key becomes
infinity (as in Juniper). The only difference from Juniper's
behavior would be that the KeyStartAccept time will be, say, 30
minutes before the router starts generating the packets with that
key (rather than starting to accept the packets NOW as in Juniper).

Consider the end-time and TimeSlack mechanism as an extention that
may not be useful for you (or for production environment in
general), but useful for people who are playing and testing things
with OSPF.

> > Instead, we plan to use a new configurable time variable, say
> > TimeSlack that is used to calculate KeyStartAccept and
> > KeyStopAccept:
> >
> > KeyStartAccept = KeyStartGenerate - TimeSlack
> > KeyStopAccept  = KeyStopGenerate + TimeSlack
> >
> > The TimeSlack variable will have a default value (say, 1800 secs),
> > and will be configurable, but typically the user won't need to do
> > anything about it.
> 
> I'm not so sure. So, instead of four selfdescriptive statements there will 
> be three relevant statements in the configuration, but one of them will 
> not be selfdescriptive in any way - it needs exact knowledge how this 
> stuff works together.

This is more of a documentation issue.

> But I have no better ideas either how to avoid "shooting into foot" 
> situations and provide end-time as well.

If somebody is really messing with the configuration, then they should
know what they are doing :)

> Btw, this reminds me the question - there is some "%help: long" statements 
> in templates. How to use them? Or isn't this implemented yet?

Good question. I guess the original idea was to use them to obtain
more verbose information about a configuration node.
E.g., "help protocols ospf4 area" should provide you with detailed
information about an OSPF area.
However, the xorpsh doesn't implement this yet, so for the time
being the "%help: long" statements are ignored.

Pavlin

From pavlin@icir.org  Tue Mar 21 03:01:27 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 20 Mar 2006 19:01:27 -0800
Subject: [Xorp-hackers] BG 172
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee>
 of "Mon, 20 Mar 2006 18:50:53 +0200." <200603201850.53289.hasso@linux.ee>
Message-ID: <200603210301.k2L31Rjq035968@possum.icir.org>

All,

So far I see strong support for removing the pair "create/set"
and having a single "set" command.

Before jumping into a final decision and taking some actions, I'd
like to clarify few things about create/set so there won't be
any surprises after their unification.

* First, a little bit extra information about "create" and "set".
  Think about "create" as the command to add new configuration
  statements.
  The "set" command is the one used to assign or change the
  value of a node _only_ if that node is already part of the
  configuration.
  As a result of that distinction, "create" needs to know about
  all possible configuration statements so it can provide the
  appropriate command-line completion. On the other hand, "set"
  provides command-line completion only about nodes that are part of
  the current configuration.

* The command-line completion behavior will change when expanding
  grouping nodes in every level of the configuration tree.

  Currently, if there is a single protocol that is configured, say
  "ospf4", if we type "set protocols" and try to perform
  command-line completion, then the command line automatically
  expands to "set protocols ospf4", because it is the only
  configured protocol (i.e., the only possible completion).
  Similarly, if "rip" was also configured, then the command-line
  completion for "set protocols" will list only "ospf4" and "rip".

  If we remove "create" and move its functionality to "set", then
  trying to perform command-line completion with the new "set"
  on command like "set protocols" will list all possible protocols.
  Such enlargement of the possible command-line completions will
  happen at every level of the configuration tree even if the only
  thing someone wants to do is modify an existing variable.

* The command-line completion behavior will change when expanding
  multi-value nodes.

  Currently, if there is say, a single OSPF area 0.0.0.0, then the
  command-line completion for "set protocols ospf4 area" will
  automatically expand to node "0.0.0.0", because it is the only
  configured area.
  With the new "set", the completion after "set protocols ospf4 area"
  will list "0.0.0.0" and "<IPv4>" as possible completions: the
  first one the existing area, and the second one as a way to add a
  new area (Note: "0.0.0.0" will be listed only after Bugzilla entry
  #330 is fixed).
  There will be such additional generic entries everywhere where we
  have multi-value nodes (interface and vif names, addresses, etc).

* With the new "set" command it becomes unclear whether we are
  modifying an existing node or creating a new one.
  To take Patrick's example (Bugzilla entry #172, Comment #2),
  let say we are using the following two commands:

set route static route4 10.0.0.0/24 next-hop 172.16.1.1
set route static route4 10.0.0.0/24 next-hop 172.16.1.2

  Currently, "next-hop" is a leaf node that can take a single value,
  hence with the old and the new "set" command we are actually
  modifying its value. However, lets say we change "next-hop" to
  be a multi-value node (e.g., along the lines of implementing
  floating static routes per Bugzilla entry #165).
  Then with the current "set" command the above two commands are
  automatically invalidated (you will get a syntax error) so it
  becomes clear "next-hop" is not a single-value node.
  With the new "set" the above two commands will be automatically
  accepted, but just by looking at them it is unclear whether the
  value of "next-hop" is modified or whether there will be two new
  nodes "next-hop": "next-hop 172.16.1.1" and "next-hop 172.16.1.2".

In other words:

A) With the new "set" command the command-line completion at every
   level gets expanded to practically everything configurable even
   if someone wants only to modify an existing value.

B) Sometimes there will be ambiguity (from user perspective) whether
   the value of a node is modified or whether a new node is added.
   This ambiguity can be cleared if you know the structure of the
   configuration tree (e.g., whether a node is single-value or
   multi-value) or if you use the "show" command to see the
   configuration before and after any modifications.


I don't consider the new behavior as a show stopper, but I want
people to understand it before we change anything.


Implementation-wise, if we go with a single "set" command, my
preference is to do the following:

1. Remove current "set", and rename existing "create" to "set".

2. Fix Bugzilla entry #330 so we get better command-completion for
   multi-value nodes.

[Note: the above two steps are what Hasso already suggests in
Bugzilla entry #172, Comment #6.]

3. Add-back a new "create" command that is just an alias for the new
  "set" command. I think we would need to keep such alias for a
   while for backward compatibility purpose until people get used to
   the new "set" command.

Comments?

Pavlin

From kristian@juniks.net  Tue Mar 21 06:11:39 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Tue, 21 Mar 2006 07:11:39 +0100
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: <200603201441.49957.hasso@linux.ee>
References: <20060319195234.GA4227@juniks.net> <200603201441.49957.hasso@linux.ee>
Message-ID: <20060321061139.GE8129@juniks.net>

On Mon, Mar 20, 2006 at 02:41:49PM +0200, Hasso Tepper wrote:
> Kristian Larsson wrote:
> > could someone please look through the Bugzilla database. There are a few 
> > bug entries for which there are patches that have not been commited to
> > CVS. Neither has there been given any reason to why they have not been 
> > commited. Would be nice to clean it up a bit :)
> 
> No offence, but some patches are in the bugzilla really too long without 
> any feedback. I know, I know ... we all have our priorities and just 
> don't find time for all stuff we'd like to do, but ...
> 
> From my position it gets harder with every new patch to maintain local 
> branch and I'd like to see patches go in or rejected and thrown away. And 
> if there is any problem with patches I, as author, can help with, please 
> say how. If patch is just crap, wrong, doesn't meet coding standards, you 
> don't agree with it at all or whatever, please say so. I fully open to 
> discussion regarding my patches.
> 
> I meant especially patches in bugzilla entries #463 and #464. But also 
> #372 and #516. And I'd be really glad if someone can take a look at #574 
> as well, some of these are really obvious problems.
I'd just like to notify you and the others on this
list that I am currently going through your
patches to verify their functionality and
recommend an action to be taken.

Just as a first not patch for BG #516 does not
apply cleanly. The addition of RFC 1583
compatibility has made some stuff look different
and so patch can't really find where to apply
things.

Regards,
  Kristian.

From kristian@juniks.net  Tue Mar 21 06:16:37 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Tue, 21 Mar 2006 07:16:37 +0100
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: <200603202255.k2KMtKSu033600@possum.icir.org>
References: <kristian@juniks.net> <20060319195234.GA4227@juniks.net> <200603202255.k2KMtKSu033600@possum.icir.org>
Message-ID: <20060321061637.GF8129@juniks.net>

On Mon, Mar 20, 2006 at 02:55:20PM -0800, Pavlin Radoslavov wrote:
> > could someone please look through the Bugzilla
> > database. There are a few bug entries for which
> > there are patches that have not been commited to
> > CVS. Neither has there been given any reason to
> > why they have not been commited. Would be nice to
> > clean it up a bit :)
> 
> We are looking at these, but usually things take time to get it done
> right. And, yes, even if there is a patch for a solution we still
> need to double-check it before applying the patch.
> 
> Though, yes, we should change the status of an entry to ASSIGNED (or
> at least put some comment) when possible so the person reporting the
> bug is not left wondering about it.

I understand you have a lot to do and I have no
problem with patches taking a little while to get
integrated into the CVS, but when there is
absolutely no sign whatsoever of activity it feels
like, "why the hell should I care when noone even
looks at my work" ;)

To aid you in your efforts I shall try to look
through a few bugs and provide additional
comments, ie "patch works for me, recommend
inclusion in CVS". More help from the community is
never a bad thing :)

Regards,
  Kristian.

From kristian@juniks.net  Tue Mar 21 06:30:13 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Tue, 21 Mar 2006 07:30:13 +0100
Subject: [Xorp-hackers] BG 172
In-Reply-To: <200603210301.k2L31Rjq035968@possum.icir.org>
References: <200603201850.53289.hasso@linux.ee> <200603210301.k2L31Rjq035968@possum.icir.org>
Message-ID: <20060321063013.GH8129@juniks.net>

On Mon, Mar 20, 2006 at 07:01:27PM -0800, Pavlin Radoslavov wrote:
> All,
> 
> So far I see strong support for removing the pair "create/set"
> and having a single "set" command.
> 
> Before jumping into a final decision and taking some actions, I'd
> like to clarify few things about create/set so there won't be
> any surprises after their unification.
> 
> * First, a little bit extra information about "create" and "set".
>   Think about "create" as the command to add new configuration
>   statements.
>   The "set" command is the one used to assign or change the
>   value of a node _only_ if that node is already part of the
>   configuration.
>   As a result of that distinction, "create" needs to know about
>   all possible configuration statements so it can provide the
>   appropriate command-line completion. On the other hand, "set"
>   provides command-line completion only about nodes that are part of
>   the current configuration.
This is a unique functionality of xorp that noone
else provides and while I agree that it on some
level is very nice (as I mentioned in a previous
letter) I think the generally accepted way of
having one set is the way to go.
> 
> * The command-line completion behavior will change when expanding
>   grouping nodes in every level of the configuration tree.
> 
>   Currently, if there is a single protocol that is configured, say
>   "ospf4", if we type "set protocols" and try to perform
>   command-line completion, then the command line automatically
>   expands to "set protocols ospf4", because it is the only
>   configured protocol (i.e., the only possible completion).
>   Similarly, if "rip" was also configured, then the command-line
>   completion for "set protocols" will list only "ospf4" and "rip".
> 
>   If we remove "create" and move its functionality to "set", then
>   trying to perform command-line completion with the new "set"
>   on command like "set protocols" will list all possible protocols.
>   Such enlargement of the possible command-line completions will
>   happen at every level of the configuration tree even if the only
>   thing someone wants to do is modify an existing variable.
Perhaps we could mark nodes to be created with *,
say you already have protocols ospf4 and you type:
set protocols <tab>
  bgp*	Border Gateway Protocol
  ospf4	OSPF
  rip*	RIP
  isis*	IS-IS

and as someone else said, when actually executing
the command, tell the user what just happened, ie:
protocols ospf4 area 0.0.0.0 node has been created
or
protocols ospf4 router-id was modified

> * The command-line completion behavior will change when expanding
>   multi-value nodes.
> 
>   Currently, if there is say, a single OSPF area 0.0.0.0, then the
>   command-line completion for "set protocols ospf4 area" will
>   automatically expand to node "0.0.0.0", because it is the only
>   configured area.
>   With the new "set", the completion after "set protocols ospf4 area"
>   will list "0.0.0.0" and "<IPv4>" as possible completions: the
>   first one the existing area, and the second one as a way to add a
>   new area (Note: "0.0.0.0" will be listed only after Bugzilla entry
>   #330 is fixed).
>   There will be such additional generic entries everywhere where we
>   have multi-value nodes (interface and vif names, addresses, etc).
> 
> * With the new "set" command it becomes unclear whether we are
>   modifying an existing node or creating a new one.
>   To take Patrick's example (Bugzilla entry #172, Comment #2),
>   let say we are using the following two commands:
> 
> set route static route4 10.0.0.0/24 next-hop 172.16.1.1
> set route static route4 10.0.0.0/24 next-hop 172.16.1.2
> 
>   Currently, "next-hop" is a leaf node that can take a single value,
>   hence with the old and the new "set" command we are actually
>   modifying its value. However, lets say we change "next-hop" to
>   be a multi-value node (e.g., along the lines of implementing
>   floating static routes per Bugzilla entry #165).
>   Then with the current "set" command the above two commands are
>   automatically invalidated (you will get a syntax error) so it
>   becomes clear "next-hop" is not a single-value node.
>   With the new "set" the above two commands will be automatically
>   accepted, but just by looking at them it is unclear whether the
>   value of "next-hop" is modified or whether there will be two new
>   nodes "next-hop": "next-hop 172.16.1.1" and "next-hop 172.16.1.2".
This is the same for ip adresses on an interface
and I think we should adopt junos style, ie don't
change anything but rather add a new route (or new
ip adress on an interface). This will make
everyone feel at home, and more importantly by
never deleting something for the user we make sure
the user needs to do a "delete" on a node thus
making it harder to shoot yourself in the foot.
Think of cisco, you have a primary ip and 50
secondaries. You add an extra address and forget
'secondary'.. whops! In JunOS this wouldn't
happen as your forced to use delete to actually
remove all the 50 adresses.

> In other words:
> 
> A) With the new "set" command the command-line completion at every
>    level gets expanded to practically everything configurable even
>    if someone wants only to modify an existing value.
> 
> B) Sometimes there will be ambiguity (from user perspective) whether
>    the value of a node is modified or whether a new node is added.
>    This ambiguity can be cleared if you know the structure of the
>    configuration tree (e.g., whether a node is single-value or
>    multi-value) or if you use the "show" command to see the
>    configuration before and after any modifications.
> 
> 
> I don't consider the new behavior as a show stopper, but I want
> people to understand it before we change anything.
> 
> 
> Implementation-wise, if we go with a single "set" command, my
> preference is to do the following:
> 
> 1. Remove current "set", and rename existing "create" to "set".
> 
> 2. Fix Bugzilla entry #330 so we get better command-completion for
>    multi-value nodes.
> 
> [Note: the above two steps are what Hasso already suggests in
> Bugzilla entry #172, Comment #6.]
> 
> 3. Add-back a new "create" command that is just an alias for the new
>   "set" command. I think we would need to keep such alias for a
>    while for backward compatibility purpose until people get used to
>    the new "set" command.
Sound like a plan. :)

Regards,
  Kristian.

From kohler@cs.ucla.edu  Tue Mar 21 07:05:29 2006
From: kohler@cs.ucla.edu (Eddie Kohler)
Date: Mon, 20 Mar 2006 23:05:29 -0800
Subject: [Xorp-hackers] BG 172
In-Reply-To: <200603210301.k2L31Rjq035968@possum.icir.org>
References: <200603210301.k2L31Rjq035968@possum.icir.org>
Message-ID: <441FA5B9.5010302@cs.ucla.edu>

Hi Pavlin, from the dumb gallery:

Thanks for this very clear mail.  The completion-based arguments for keeping 
"set" as is aren't very convincing, I think.  This one is tougher:

> * With the new "set" command it becomes unclear whether we are
>   modifying an existing node or creating a new one.
>   To take Patrick's example (Bugzilla entry #172, Comment #2),
>   let say we are using the following two commands:
> 
> set route static route4 10.0.0.0/24 next-hop 172.16.1.1
> set route static route4 10.0.0.0/24 next-hop 172.16.1.2

It is really problematic when code or configuration statements silently change 
meaning from one release to the next!

So, followon question.  Can you enumerate those places in the configuration 
tree that are single-value now, but are likely to become multi-value in 
future?  If so then they could be specially marked so they behave like 
multi-value even now.  That is, if you entered the above statements, you would 
get:

 > set route static route4 10.0.0.0/24 next-hop 172.16.1.1
[OK]
 > set route static route4 10.0.0.0/24 next-hop 172.16.1.2
[ERROR: eventually you will be able to add multiple next-hops for a given
route, but for now, you must delete the old next-hop before setting a new one.]

Does this make sense?

Also, you could also keep "create" around with the current semantics, so the 
user could express the intent to create a new node when appropriate.
Eddie



> 
>   Currently, "next-hop" is a leaf node that can take a single value,
>   hence with the old and the new "set" command we are actually
>   modifying its value. However, lets say we change "next-hop" to
>   be a multi-value node (e.g., along the lines of implementing
>   floating static routes per Bugzilla entry #165).
>   Then with the current "set" command the above two commands are
>   automatically invalidated (you will get a syntax error) so it
>   becomes clear "next-hop" is not a single-value node.
>   With the new "set" the above two commands will be automatically
>   accepted, but just by looking at them it is unclear whether the
>   value of "next-hop" is modified or whether there will be two new
>   nodes "next-hop": "next-hop 172.16.1.1" and "next-hop 172.16.1.2".
> 
> In other words:
> 
> A) With the new "set" command the command-line completion at every
>    level gets expanded to practically everything configurable even
>    if someone wants only to modify an existing value.
> 
> B) Sometimes there will be ambiguity (from user perspective) whether
>    the value of a node is modified or whether a new node is added.
>    This ambiguity can be cleared if you know the structure of the
>    configuration tree (e.g., whether a node is single-value or
>    multi-value) or if you use the "show" command to see the
>    configuration before and after any modifications.
> 
> 
> I don't consider the new behavior as a show stopper, but I want
> people to understand it before we change anything.
> 
> 
> Implementation-wise, if we go with a single "set" command, my
> preference is to do the following:
> 
> 1. Remove current "set", and rename existing "create" to "set".
> 
> 2. Fix Bugzilla entry #330 so we get better command-completion for
>    multi-value nodes.
> 
> [Note: the above two steps are what Hasso already suggests in
> Bugzilla entry #172, Comment #6.]
> 
> 3. Add-back a new "create" command that is just an alias for the new
>   "set" command. I think we would need to keep such alias for a
>    while for backward compatibility purpose until people get used to
>    the new "set" command.
> 
> Comments?
> 
> Pavlin
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

From hasso@linux.ee  Tue Mar 21 08:45:37 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Tue, 21 Mar 2006 10:45:37 +0200
Subject: [Xorp-hackers] BG 172
In-Reply-To: <441FA5B9.5010302@cs.ucla.edu>
References: <200603210301.k2L31Rjq035968@possum.icir.org> <441FA5B9.5010302@cs.ucla.edu>
Message-ID: <200603211045.37829.hasso@linux.ee>

Eddie Kohler wrote:
> > set route static route4 10.0.0.0/24 next-hop 172.16.1.1
> > set route static route4 10.0.0.0/24 next-hop 172.16.1.2
>
> It is really problematic when code or configuration statements silently
> change meaning from one release to the next!

No, it isn't problematic. Xorp doesn't handle non-unique leaf nodes at all 
at the moment, so there is nothing that breaks really. Policy with new 
set command should be clear: it must change unique nodes and add 
non-unique ones.

As sidenote (it shouldn't matter any more), what would happen in 
hypotetical case (if multiple nexthops would be supported) with current 
set behaviour?

create route static route4 10.0.0.0/24 next-hop 172.16.1.1
create route static route4 10.0.0.0/24 next-hop 172.16.1.2
set route static route4 10.0.0.0/24 next-hop 172.16.1.3

> So, followon question.  Can you enumerate those places in the
> configuration tree that are single-value now, but are likely to become
> multi-value in future?  If so then they could be specially marked so
> they behave like multi-value even now.  That is, if you entered the
> above statements, you would
>
> get:
>  > set route static route4 10.0.0.0/24 next-hop 172.16.1.1
>
> [OK]
>
>  > set route static route4 10.0.0.0/24 next-hop 172.16.1.2
>
> [ERROR: eventually you will be able to add multiple next-hops for a
> given route, but for now, you must delete the old next-hop before
> setting a new one.]
>
> Does this make sense?

IMHO no. Please keep clippy attitude [1] away of my routers ;).


[1] - http://www.gryniewicz.com/dang/blog/wp-content/vim.gif

-- 
Hasso

From hasso@linux.ee  Tue Mar 21 12:34:44 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Tue, 21 Mar 2006 14:34:44 +0200
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: <200603210118.k2L1Iris035157@possum.icir.org>
References: <200603210118.k2L1Iris035157@possum.icir.org>
Message-ID: <200603211434.44700.hasso@linux.ee>

Pavlin Radoslavov wrote:
> The example you gave about RFC 2328 Appendix B is about changing
> protocol parameters. This is typically allowed when
> implementing/configuring a protocol.

No, these are architectural constants in the appendix B. Configurable 
constants are in the appendix C.

> The Cisco's change I am referring to is about a not-so elegant
> deviation from the spec.

But it's simple and just works. Almost zero chance you can shoot yourself 
into foot (unless you really try hard :).

> > I don't see the any need for such behaviour. I already said that I
> > take this kind of automatic dangerous.
>
> I understand that in your production environment (and probably
> everybody else's) you want strict control.
> With our solution we don't take this control away from you.

Yes, I understand it. No problem or objections here.

> This is more of a documentation issue.

It's always better to have clear and selfdescriptive commands. If it's 
just documentation issue, why not have just "coa 0" instead of "create 
ospf area 0.0.0.0"? Much less typing etc ;).

Note, that this kind of cli's exist actually. I had to do some work with 
cli where all commands were just this kind of five letters "words" with 
argument. It did the job, but it doesn't mean that I enjoyed it ;).
 
> Good question. I guess the original idea was to use them to obtain
> more verbose information about a configuration node.
> E.g., "help protocols ospf4 area" should provide you with detailed
> information about an OSPF area.
> However, the xorpsh doesn't implement this yet, so for the time
> being the "%help: long" statements are ignored.

OK, clear. Is it worth of effort to open enhancement request in bugzilla 
regarding this?


-- 
Hasso

From hasso@linux.ee  Tue Mar 21 16:45:17 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Tue, 21 Mar 2006 18:45:17 +0200
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: <20060321061139.GE8129@juniks.net>
References: <20060319195234.GA4227@juniks.net> <200603201441.49957.hasso@linux.ee> <20060321061139.GE8129@juniks.net>
Message-ID: <200603211845.17144.hasso@linux.ee>

Kristian Larsson wrote:
> Just as a first not patch for BG #516 does not
> apply cleanly. The addition of RFC 1583
> compatibility has made some stuff look different
> and so patch can't really find where to apply
> things.

I just attached rediffed patch to the #516.


-- 
Hasso Tepper

From pavlin@icir.org  Tue Mar 21 19:46:21 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 21 Mar 2006 11:46:21 -0800
Subject: [Xorp-hackers] BG 172
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee>
 of "Tue, 21 Mar 2006 10:45:37 +0200." <200603211045.37829.hasso@linux.ee>
Message-ID: <200603211946.k2LJkLYn057958@possum.icir.org>

> Eddie Kohler wrote:
> > > set route static route4 10.0.0.0/24 next-hop 172.16.1.1
> > > set route static route4 10.0.0.0/24 next-hop 172.16.1.2
> >
> > It is really problematic when code or configuration statements silently
> > change meaning from one release to the next!
> 
> No, it isn't problematic. Xorp doesn't handle non-unique leaf nodes at all 
> at the moment, so there is nothing that breaks really. Policy with new 
> set command should be clear: it must change unique nodes and add 
> non-unique ones.

I believe the point Eddie was trying to make is that someone
accustomed with the current "set" command being used only to change
values of single-value nodes will suddenly start seeing different
behavior with the new "set" if we redefine a single-value node as a
multi-value node.

Yes, this could be a problem when using xorpsh, so at least we
should try to avoid redefining a single-value node as a multi-value
(or vice versa).

> As sidenote (it shouldn't matter any more), what would happen in 
> hypotetical case (if multiple nexthops would be supported) with current 
> set behaviour?
> 
> create route static route4 10.0.0.0/24 next-hop 172.16.1.1
> create route static route4 10.0.0.0/24 next-hop 172.16.1.2
> set route static route4 10.0.0.0/24 next-hop 172.16.1.3

The first two commands will create two next-hop nodes: 172.16.1.1
and 172.16.1.2.
The third command will return a syntax error.

Pavlin

From kohler@cs.ucla.edu  Tue Mar 21 20:19:33 2006
From: kohler@cs.ucla.edu (Eddie Kohler)
Date: Tue, 21 Mar 2006 12:19:33 -0800
Subject: [Xorp-hackers] BG 172
In-Reply-To: <200603211946.k2LJkLYn057958@possum.icir.org>
References: <200603211946.k2LJkLYn057958@possum.icir.org>
Message-ID: <186A8999-DE73-4E02-BECB-651433EF9659@CS.UCLA.EDU>

Thanks P -- that is exactly what I had meant.

E


On Mar 21, 2006, at 11:46 AM, Pavlin Radoslavov wrote:

>> Eddie Kohler wrote:
>>>> set route static route4 10.0.0.0/24 next-hop 172.16.1.1
>>>> set route static route4 10.0.0.0/24 next-hop 172.16.1.2
>>>
>>> It is really problematic when code or configuration statements  
>>> silently
>>> change meaning from one release to the next!
>>
>> No, it isn't problematic. Xorp doesn't handle non-unique leaf  
>> nodes at all
>> at the moment, so there is nothing that breaks really. Policy with  
>> new
>> set command should be clear: it must change unique nodes and add
>> non-unique ones.
>
> I believe the point Eddie was trying to make is that someone
> accustomed with the current "set" command being used only to change
> values of single-value nodes will suddenly start seeing different
> behavior with the new "set" if we redefine a single-value node as a
> multi-value node.
>
> Yes, this could be a problem when using xorpsh, so at least we
> should try to avoid redefining a single-value node as a multi-value
> (or vice versa).
>
>> As sidenote (it shouldn't matter any more), what would happen in
>> hypotetical case (if multiple nexthops would be supported) with  
>> current
>> set behaviour?
>>
>> create route static route4 10.0.0.0/24 next-hop 172.16.1.1
>> create route static route4 10.0.0.0/24 next-hop 172.16.1.2
>> set route static route4 10.0.0.0/24 next-hop 172.16.1.3
>
> The first two commands will create two next-hop nodes: 172.16.1.1
> and 172.16.1.2.
> The third command will return a syntax error.
>
> Pavlin
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From pavlin@icir.org  Tue Mar 21 20:42:43 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 21 Mar 2006 12:42:43 -0800
Subject: [Xorp-hackers] OSPF auth...
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee>
 of "Tue, 21 Mar 2006 14:34:44 +0200." <200603211434.44700.hasso@linux.ee>
Message-ID: <200603212042.k2LKghci058512@possum.icir.org>

> > Good question. I guess the original idea was to use them to obtain
> > more verbose information about a configuration node.
> > E.g., "help protocols ospf4 area" should provide you with detailed
> > information about an OSPF area.
> > However, the xorpsh doesn't implement this yet, so for the time
> > being the "%help: long" statements are ignored.
> 
> OK, clear. Is it worth of effort to open enhancement request in bugzilla 
> regarding this?

You could, but most likely it will go to the end of our priority
queue :)

Anyway, I just created the bugzilla entry myself, so feel free to
add any extra info there:
http://www.xorp.org/bugzilla/show_bug.cgi?id=592

Pavlin

From pavlin@icir.org  Wed Mar 22 00:00:28 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 21 Mar 2006 16:00:28 -0800
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: Message from Kristian Larsson <kristian@juniks.net>
 of "Tue, 21 Mar 2006 07:16:37 +0100." <20060321061637.GF8129@juniks.net>
Message-ID: <200603220000.k2M00S1Y060171@possum.icir.org>

> On Mon, Mar 20, 2006 at 02:55:20PM -0800, Pavlin Radoslavov wrote:
> > > could someone please look through the Bugzilla
> > > database. There are a few bug entries for which
> > > there are patches that have not been commited to
> > > CVS. Neither has there been given any reason to
> > > why they have not been commited. Would be nice to
> > > clean it up a bit :)
> > 
> > We are looking at these, but usually things take time to get it done
> > right. And, yes, even if there is a patch for a solution we still
> > need to double-check it before applying the patch.
> > 
> > Though, yes, we should change the status of an entry to ASSIGNED (or
> > at least put some comment) when possible so the person reporting the
> > bug is not left wondering about it.
> 
> I understand you have a lot to do and I have no
> problem with patches taking a little while to get
> integrated into the CVS, but when there is
> absolutely no sign whatsoever of activity it feels
> like, "why the hell should I care when noone even
> looks at my work" ;)

I understand and I apologize again for dropping the ball on that.
>From now on we will try to do better job so things are not left in
the dark.

> To aid you in your efforts I shall try to look
> through a few bugs and provide additional
> comments, ie "patch works for me, recommend
> inclusion in CVS". More help from the community is
> never a bad thing :)

Thank you.

Pavlin

From mike@lrlart.com  Thu Mar 23 21:17:49 2006
From: mike@lrlart.com (mike@lrlart.com)
Date: Thu, 23 Mar 2006 14:17:49 -0700
Subject: [Xorp-hackers] xorp callback construction
Message-ID: <20060323141749.8c0fa638fcef9dd13f5a2f992b1941af.80048c919d.wbe@email.email.secureserver.net>

Hey all,

I'm running into a compile error that I am unable to circumvent. I
written a xorp module that sends commands to the fea, but in
constructing the callback to be dispatched to
XrlIfmgrV0p1Client::send_start_transaction(), I have the following
line, which should instantiate the start transaction callback:

uint32_t tid;
XrlIfmgrV0p1Client::StartTransactionCB cb2 =
XrlIfmgrV0p1Client::StartTransactionCB(this,
&XrlRLInterfacesNode::send_start_transaction_cb, &tid);

The "this" object is a child class that derives from
 class XrlRLInterfacesNode :     public XrlStdRouter, /* used for
dispatch of xrl messages */
                            public XrlRlInterfacesTargetBase { /* used
for defined interface */

However, the compilier is unhappy with the instantiation of the
StartTransactionCB object though:

xrl_rl_interfaces_node.cc:943: error: no matching function for call to
`ref_ptr<XorpCallback2<void, const XrlError&, const uint32_t*>
>::ref_ptr(XrlRLInterfacesNode* const, void
(XrlRLInterfacesNode::*)(const XrlError&, const uint32_t*), uint32_t*)'
../libxorp/ref_ptr.hh:247: note: candidates are:
ref_ptr<_Tp>::ref_ptr(_Tp*, int32_t) [with _Tp = XorpCallback2<void,
const XrlError&, const uint32_t*>]
../libxorp/ref_ptr.hh:149: note:                
ref_ptr<_Tp>::ref_ptr(const ref_ptr<_Tp>&) [with _Tp =
XorpCallback2<void, const XrlError&, const uint32_t*>]
../libxorp/ref_ptr.hh:136: note:                
ref_ptr<_Tp>::ref_ptr(_Tp*) [with _Tp = XorpCallback2<void, const
XrlError&, const uint32_t*>]

The callback method is defined as:

void send_start_transaction_cb(const XrlError &xrl_error, const uint32_t
*tid);

So, it looks as if my callback method isn't defined correctly, but in
searching through the xorp source--but it looks correct to me (but I'm
probably missing something obvious). 

Thanks for any help!


Mike Larson


From pavlin@icir.org  Thu Mar 23 23:49:12 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 23 Mar 2006 15:49:12 -0800
Subject: [Xorp-hackers] xorp callback construction
In-Reply-To: Message from mike@lrlart.com
 of "Thu, 23 Mar 2006 14:17:49 MST." <20060323141749.8c0fa638fcef9dd13f5a2f992b1941af.80048c919d.wbe@email.email.secureserver.net>
Message-ID: <200603232349.k2NNnC3O088332@possum.icir.org>

> I'm running into a compile error that I am unable to circumvent. I
> written a xorp module that sends commands to the fea, but in
> constructing the callback to be dispatched to
> XrlIfmgrV0p1Client::send_start_transaction(), I have the following
> line, which should instantiate the start transaction callback:
> 
> uint32_t tid;
> XrlIfmgrV0p1Client::StartTransactionCB cb2 =
> XrlIfmgrV0p1Client::StartTransactionCB(this,
> &XrlRLInterfacesNode::send_start_transaction_cb, &tid);

Try something like this (off the top of my head):

    bool success;
    XrlIfmgrV0p1Client client(&xrl_router);

    success = client.send_start_transaction(fea_target_name.c_str(),
	callback(this,  &XrlRLInterfacesNode::send_start_transaction_cb));
    if (success != true) {
       // Handle XRL transmission error
       ...
    }
    ...

where the callback method must be like:

void
XrlRLInterfacesNode::send_start_transaction_cb(const XrlError& xrl_error,
                                               const uint32_t* tid)
{
    switch (xrl_error.error_code()) {
    case OKAY:
	// Use the value of *tid
	break;
    ....
    // Switch cases to handle all other XRL errors
    }
}


Pavlin


> 
> The "this" object is a child class that derives from
>  class XrlRLInterfacesNode :     public XrlStdRouter, /* used for
> dispatch of xrl messages */
>                             public XrlRlInterfacesTargetBase { /* used
> for defined interface */
> 
> However, the compilier is unhappy with the instantiation of the
> StartTransactionCB object though:
> 
> xrl_rl_interfaces_node.cc:943: error: no matching function for call to
> `ref_ptr<XorpCallback2<void, const XrlError&, const uint32_t*>
> >::ref_ptr(XrlRLInterfacesNode* const, void
> (XrlRLInterfacesNode::*)(const XrlError&, const uint32_t*), uint32_t*)'
> ../libxorp/ref_ptr.hh:247: note: candidates are:
> ref_ptr<_Tp>::ref_ptr(_Tp*, int32_t) [with _Tp = XorpCallback2<void,
> const XrlError&, const uint32_t*>]
> ../libxorp/ref_ptr.hh:149: note:                
> ref_ptr<_Tp>::ref_ptr(const ref_ptr<_Tp>&) [with _Tp =
> XorpCallback2<void, const XrlError&, const uint32_t*>]
> ../libxorp/ref_ptr.hh:136: note:                
> ref_ptr<_Tp>::ref_ptr(_Tp*) [with _Tp = XorpCallback2<void, const
> XrlError&, const uint32_t*>]
> 
> The callback method is defined as:
> 
> void send_start_transaction_cb(const XrlError &xrl_error, const uint32_t
> *tid);
> 
> So, it looks as if my callback method isn't defined correctly, but in
> searching through the xorp source--but it looks correct to me (but I'm
> probably missing something obvious). 
> 
> Thanks for any help!
> 
> 
> Mike Larson
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From kristian@juniks.net  Fri Mar 24 13:01:04 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Fri, 24 Mar 2006 14:01:04 +0100
Subject: [Xorp-hackers] BG 172
In-Reply-To: <9280364.7211142869104285.JavaMail.root@mail.vyatta.com>
References: <9280364.7211142869104285.JavaMail.root@mail.vyatta.com>
Message-ID: <20060324130104.GA32597@juniks.net>

Dear developers,

as the view on the matter seems unanimous I wonder
if we can conclude this or if we need more input?
We could perhaps ask the same question on the
vyatta-users mailing list.

Regards,
Kristian Larsson


On Mon, Mar 20, 2006 at 07:38:24AM -0800, Mike Horn wrote:
> Another vote for removing "create" and having "set" and "edit" create the intermediary nodes.  I can understand the initial logic in having the set vs. create, but I think it causes more confusion than it eliminates.
> 
> -mike
> 
> 
> ----- Original Message -----
> From: Hasso Tepper <hasso@linux.ee>
> To: xorp-hackers@icir.org
> Sent: Monday, March 20, 2006 2:48:36 AM GMT-0700
> Subject: Re: [Xorp-hackers] BG 172
> 
> Mark Handley wrote:
> > The reason for the create command was to make it obvious to the user
> > the difference between creating a node where there can be many (such
> > as creating peers in BGP, or adding addresses to an interface), and
> > setting a parameter (when it's only possible to have one value, such
> > as the holdtime on a particular peering).
> 
> You are assuming here that user should know exact structure of all 
> configuration statements which is insane.
> 
> > This was supposed to be less confusing to the user - the two behaviours 
> > are fundamentally different, and using a single command means the user 
> > can't tell from the command which behaviour will occur.
> 
> While entering new statements into configuration users don't care how the 
> result will appear in configuration - whether command ends with 
> intermediate or leaf node. They don't need that knowledge. They need this 
> knowledge while working with existing configuration and then they already 
> see how configuration structure with "show" command. 
> 
> > With hindsight though, it's not clear to me if it is in fact less
> > confusing.  But it's hard to tell, because my worldview is distorted
> > by using XORP, and other's worldviews are clearly distorted by using
> > Juniper boxes.
> 
> It's Junos vs. Xorp topic, it's general usability issue. There are two 
> ways to start entering configuration command in Xorp - create vs. set. I 
> don't know any other CLI behaving this way. User don't know exactly how 
> configuration is built up. He presses tab and discovers logical path to 
> configuration he/she wants. And using both create and set means a lot of 
> more typing for user.
> 
> "I want to default LSA into ospf area with metric 10 , lets find out ... 
> "set ?" ... "protocols " ... "ospf " ... "area 0.0.0.10 " ... hmmm, no 
> any word about default ... argh, I have to create it before. "create 
> protocols ospf area 0.0.0.10 default-lsa", "set protocols ospf area 
> 0.0.0.10 default-lsa metric 10" etc."
> 
> In all other CLI's there is only one path - to enter one configuration 
> statement you don't have to go back to the beginning of the entering 
> statement.
> 
> All Xorp users (testers actually) I know at the moment (including me) just 
> use create command and take two issues as annoying bugs - difference from 
> Junos cli and that create doesn't complete existing intermediate node 
> names.
> 
> 
> -- 
> Hasso Tepper
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

From pavlin@icir.org  Fri Mar 24 19:33:17 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 24 Mar 2006 11:33:17 -0800
Subject: [Xorp-hackers] BG 172
In-Reply-To: Message from Kristian Larsson <kristian@juniks.net>
 of "Fri, 24 Mar 2006 14:01:04 +0100." <20060324130104.GA32597@juniks.net>
Message-ID: <200603241933.k2OJXHCw039301@possum.icir.org>

> Dear developers,
> 
> as the view on the matter seems unanimous I wonder
> if we can conclude this or if we need more input?
> We could perhaps ask the same question on the
> vyatta-users mailing list.

I think there was an implicit agreement we should go with the
"create/set" merger. It didn't seem there are any issues
that need additional resolving or are potential show stoppers.
If I am missing something please correct me.
If someone has something additional in mind, now is the time to
bring it on.

It is up to you whether you want to bring the subject on the
vyatta-users mailing list. However, you would have to bring back the
highlights of the discussion there back to this thread :)

Pavlin

From kristian@juniks.net  Sat Mar 25 17:15:12 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Sat, 25 Mar 2006 18:15:12 +0100
Subject: [Xorp-hackers] BG 172
In-Reply-To: <200603241933.k2OJXHCw039301@possum.icir.org>
References: <kristian@juniks.net> <20060324130104.GA32597@juniks.net> <200603241933.k2OJXHCw039301@possum.icir.org>
Message-ID: <20060325171512.GA26983@juniks.net>

On Fri, Mar 24, 2006 at 11:33:17AM -0800, Pavlin Radoslavov wrote:
> > Dear developers,
> > 
> > as the view on the matter seems unanimous I wonder
> > if we can conclude this or if we need more input?
> > We could perhaps ask the same question on the
> > vyatta-users mailing list.
> 
> I think there was an implicit agreement we should go with the
> "create/set" merger. It didn't seem there are any issues
> that need additional resolving or are potential show stoppers.
> If I am missing something please correct me.
> If someone has something additional in mind, now is the time to
> bring it on.
I just wanted it confirmed :)

From pavlin@icir.org  Mon Mar 27 09:04:58 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 27 Mar 2006 01:04:58 -0800
Subject: [Xorp-hackers] HEADS UP: XORP configuration syntax changes
Message-ID: <200603270904.k2R94wKf037136@possum.icir.org>

All,

As of today, there are few changes in the XORP configuration syntax
in XORP-current, and those changes will be in the next XORP-1.3
release as well.

The changes are:
 * Deprecate the following statements for configuring static routes:
     route4
     route6
     interface-route4
     interface-route6
     mrib-route4
     mrib-route6
     mrib-interface-route4
     mrib-interface-route6

  The new replacement statements are:
    route
    interface-route
    mrib-route
    mrib-interface-route

  Each of the new statements can be used to configure either IPv4Net
  or IPv6Net route.

Please let us know if you find any problems because of the above
change.

Thank you,
The XORP Team

From kristian@juniks.net  Thu Mar 30 13:36:57 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Thu, 30 Mar 2006 15:36:57 +0200
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: <200603220000.k2M00S1Y060171@possum.icir.org>
References: <kristian@juniks.net> <20060321061637.GF8129@juniks.net> <200603220000.k2M00S1Y060171@possum.icir.org>
Message-ID: <20060330133656.GC24663@juniks.net>

On Tue, Mar 21, 2006 at 04:00:28PM -0800, Pavlin Radoslavov wrote:
> > On Mon, Mar 20, 2006 at 02:55:20PM -0800, Pavlin Radoslavov wrote:
> > > > could someone please look through the Bugzilla
> > > > database. There are a few bug entries for which
> > > > there are patches that have not been commited to
> > > > CVS. Neither has there been given any reason to
> > > > why they have not been commited. Would be nice to
> > > > clean it up a bit :)
> > > 
> > > We are looking at these, but usually things take time to get it done
> > > right. And, yes, even if there is a patch for a solution we still
> > > need to double-check it before applying the patch.
> > > 
> > > Though, yes, we should change the status of an entry to ASSIGNED (or
> > > at least put some comment) when possible so the person reporting the
> > > bug is not left wondering about it.
> > 
> > I understand you have a lot to do and I have no
> > problem with patches taking a little while to get
> > integrated into the CVS, but when there is
> > absolutely no sign whatsoever of activity it feels
> > like, "why the hell should I care when noone even
> > looks at my work" ;)
> 
> I understand and I apologize again for dropping the ball on that.
> From now on we will try to do better job so things are not left in
> the dark.
> 
> > To aid you in your efforts I shall try to look
> > through a few bugs and provide additional
> > comments, ie "patch works for me, recommend
> > inclusion in CVS". More help from the community is
> > never a bad thing :)
> 
> Thank you.


I would like to see #199 commited to CVS and I
will open up a bug report soon just as I'm sure I
have looked through all the previous. Don't want
to create a duplicate.
Anyway my current problem lies in that my
configuration contains:
        bgp {
            bgp-id: 195.182.5.253
            local-as: 39525
            peer "217.10.127.13" {
                as: 35706
                next-hop: 217.10.127.13
                local-ip: "217.10.127.14"
            }
        }
but xorp_bgp seems to have crashed.
I would now like to do a 'commit full' so that bgp
is restarted. I do not want to loose OSPF
connectivity (ie, don't restart entire XORP) so
currently my only solution seems to be to delete
the bgp part of the configuration and readd it
again.

Anyway, as stated I think the commit command
should be available all the time, as suggest by
#199.

Thank you
Regards,
  Kristian.


From Ambiga@amedia.com  Thu Mar 30 15:23:02 2006
From: Ambiga@amedia.com (Ambiga Karthikeyan)
Date: Thu, 30 Mar 2006 10:23:02 -0500
Subject: [Xorp-hackers] FW: Triggered RIP support (RFC 2091)
Message-ID: <9025E129D3FCD340A7BA67E342D10E7A12141E48@ms06.mse1.mailstreet.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6540D.282F9FB9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

________________________________

From: Ambiga Karthikeyan=20
Sent: Thursday, March 30, 2006 10:17 AM
To: 'xorp-users@xorp.org'
Cc: 'xorp-hackers@xorp.org'
Subject: Triggered RIP support (RFC 2091)

=20

All,

=20

    Does XORP have support for triggered rip extension (rfc 2091). From
the documents that I read, it doesn't look like XORP supports it but
just wanted to confirm.

=20

Thanks,

Ambiga


------_=_NextPart_001_01C6540D.282F9FB9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
<st1:PersonName
w:st=3D"on">Ambiga Karthikeyan</st1:PersonName> <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, March 30, =
2006
10:17 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
'xorp-users@xorp.org'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
'xorp-hackers@xorp.org'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Triggered RIP =
support
(RFC 2091)</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>All,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp; Does XORP have support for =
triggered rip
extension (rfc 2091). From the documents that I read, it doesn&#8217;t =
look
like XORP supports it but just wanted to =
confirm.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Ambiga<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6540D.282F9FB9--


From oho@acm.org  Thu Mar 30 16:04:09 2006
From: oho@acm.org (Orion Hodson)
Date: Thu, 30 Mar 2006 08:04:09 -0800
Subject: [Xorp-hackers] FW: Triggered RIP support (RFC 2091)
In-Reply-To: <9025E129D3FCD340A7BA67E342D10E7A12141E48@ms06.mse1.mailstreet.com>
References: <9025E129D3FCD340A7BA67E342D10E7A12141E48@ms06.mse1.mailstreet.com>
Message-ID: <542100F7-8EE0-4C2C-8031-BE2FAD839441@acm.org>

--Apple-Mail-85-71208964
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=WINDOWS-1252;
	delsp=yes;
	format=flowed

No, it doesn't.  AFAIK XORP doesn't have any concept of demand circuits.
- Orion



On Mar 30, 2006, at 7:23 AM, Ambiga Karthikeyan wrote:

>
>
>
>
> From: Ambiga Karthikeyan
> Sent: Thursday, March 30, 2006 10:17 AM
> To: 'xorp-users@xorp.org'
> Cc: 'xorp-hackers@xorp.org'
> Subject: Triggered RIP support (RFC 2091)
>
>
>
> All,
>
>
>
>     Does XORP have support for triggered rip extension (rfc 2091). =20
> =46rom the documents that I read, it doesn=92t look like XORP supports =
=20
> it but just wanted to confirm.
>
>
>
> Thanks,
>
> Ambiga
>
>


--Apple-Mail-85-71208964
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=WINDOWS-1252

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>No, it doesn't.=A0 AFAIK =
XORP doesn't have any concept of demand circuits.</DIV><DIV>- =
Orion</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><BR><DIV><DIV>On Mar 30, 2006, =
at 7:23 AM, Ambiga Karthikeyan wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><SPAN =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><O:SMARTTAGTYPE =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"><DIV class=3D"Section1"><P class=3D"MsoNormal"><FONT =
size=3D"2" color=3D"navy" face=3D"Arial"><SPAN style=3D"font-size: =
10.0pt;font-family:Arial;color:navy; color: rgb(0, 0, 128); font-size: =
13.3333px; "><O:P style=3D"color: rgb(0, 0, 128); font-family: Arial; =
font-size: 13.3333px; "><SPAN class=3D"Apple-style-span" style=3D"color: =
rgb(0, 0, 128); font-family: Arial; font-size: 13.3333px; =
">=A0</SPAN></O:P></SPAN></FONT></P><P class=3D"MsoNormal"><FONT =
size=3D"2" color=3D"navy" face=3D"Arial"><SPAN style=3D"font-size: =
10.0pt;font-family:Arial;color:navy; color: rgb(0, 0, 128); font-size: =
13.3333px; "><O:P style=3D"color: rgb(0, 0, 128); font-family: Arial; =
font-size: 13.3333px; "><SPAN class=3D"Apple-style-span" style=3D"color: =
rgb(0, 0, 128); font-family: Arial; font-size: 13.3333px; =
">=A0</SPAN></O:P></SPAN></FONT></P><DIV><DIV class=3D"MsoNormal" =
align=3D"center" style=3D"text-align:center; font-family: Times New =
Roman; font-size: 16px; "><FONT size=3D"3" face=3D"Times New =
Roman"><SPAN style=3D"font-size:12.0pt; font-family: Times New Roman; =
font-size: 16px; text-align: center; "><SPAN class=3D"Apple-style-span" =
style=3D"font-family: Times New Roman; font-size: 16px; text-align: =
center; "></SPAN><HR size=3D"2" width=3D"100%" align=3D"center" =
tabindex=3D"-1"></SPAN></FONT></DIV><P class=3D"MsoNormal"><B =
style=3D"font-family: Times New Roman; font-size: 16px; font-weight: =
bold; "><FONT size=3D"2" face=3D"Tahoma"><SPAN style=3D"font-size:10.0pt; =
font-family:Tahoma;font-weight:bold; font-size: 13.3333px; "><SPAN =
class=3D"Apple-style-span" style=3D"font-family: Tahoma; font-size: =
13.3333px; font-weight: bold; ">From:</SPAN></SPAN></FONT></B><FONT =
size=3D"2" face=3D"Tahoma"><SPAN =
style=3D"font-size:10.0pt;font-family:Tahoma; font-size: 13.3333px; =
"><SPAN class=3D"Apple-style-span" style=3D"font-family: Tahoma; =
font-size: 13.3333px; "> </SPAN><ST1:PERSONNAME w:st=3D"on"><SPAN =
class=3D"Apple-style-span" style=3D"font-family: Tahoma; font-size: =
13.3333px; ">Ambiga Karthikeyan</SPAN></ST1:PERSONNAME><SPAN =
class=3D"Apple-style-span" style=3D"font-family: Tahoma; font-size: =
13.3333px; "> </SPAN><BR style=3D"font-family: Tahoma; font-size: =
13.3333px; "><B style=3D"font-family: Tahoma; font-size: 13.3333px; =
font-weight: bold; "><SPAN style=3D"font-weight:bold; font-family: =
Tahoma; font-size: 13.3333px; "><SPAN class=3D"Apple-style-span" =
style=3D"font-family: Tahoma; font-size: 13.3333px; font-weight: bold; =
">Sent:</SPAN></SPAN></B><SPAN class=3D"Apple-style-span" =
style=3D"font-family: Tahoma; font-size: 13.3333px; "> Thursday, March =
30, 2006 10:17 AM</SPAN><BR style=3D"font-family: Tahoma; font-size: =
13.3333px; "><B style=3D"font-family: Tahoma; font-size: 13.3333px; =
font-weight: bold; "><SPAN style=3D"font-weight:bold; font-family: =
Tahoma; font-size: 13.3333px; "><SPAN class=3D"Apple-style-span" =
style=3D"font-family: Tahoma; font-size: 13.3333px; font-weight: bold; =
">To:</SPAN></SPAN></B><SPAN class=3D"Apple-style-span" =
style=3D"font-family: Tahoma; font-size: 13.3333px; "> '<A =
href=3D"mailto:xorp-users@xorp.org">xorp-users@xorp.org</A>'</SPAN><BR =
style=3D"font-family: Tahoma; font-size: 13.3333px; "><B =
style=3D"font-family: Tahoma; font-size: 13.3333px; font-weight: bold; =
"><SPAN style=3D"font-weight:bold; font-family: Tahoma; font-size: =
13.3333px; "><SPAN class=3D"Apple-style-span" style=3D"font-family: =
Tahoma; font-size: 13.3333px; font-weight: bold; =
">Cc:</SPAN></SPAN></B><SPAN class=3D"Apple-style-span" =
style=3D"font-family: Tahoma; font-size: 13.3333px; "> '<A =
href=3D"mailto:xorp-hackers@xorp.org">xorp-hackers@xorp.org</A>'</SPAN><BR=
 style=3D"font-family: Tahoma; font-size: 13.3333px; "><B =
style=3D"font-family: Tahoma; font-size: 13.3333px; font-weight: bold; =
"><SPAN style=3D"font-weight:bold; font-family: Tahoma; font-size: =
13.3333px; "><SPAN class=3D"Apple-style-span" style=3D"font-family: =
Tahoma; font-size: 13.3333px; font-weight: bold; =
">Subject:</SPAN></SPAN></B><SPAN class=3D"Apple-style-span" =
style=3D"font-family: Tahoma; font-size: 13.3333px; "> Triggered RIP =
support (RFC 2091)</SPAN></SPAN></FONT><O:P style=3D"font-family: Times =
New Roman; font-size: 16px; "></O:P></P></DIV><P class=3D"MsoNormal"><FONT=
 size=3D"3" face=3D"Times New Roman"><SPAN style=3D"font-size: 12.0pt; =
font-family: Times New Roman; font-size: 16px; "><O:P =
style=3D"font-family: Times New Roman; font-size: 16px; "><SPAN =
class=3D"Apple-style-span" style=3D"font-family: Times New Roman; =
font-size: 16px; ">=A0</SPAN></O:P></SPAN></FONT></P><P =
class=3D"MsoNormal"><FONT size=3D"2" face=3D"Arial"><SPAN =
style=3D"font-size:10.0pt; font-family:Arial; font-size: 13.3333px; =
"><SPAN class=3D"Apple-style-span" style=3D"font-family: Arial; =
font-size: 13.3333px; ">All,</SPAN><O:P style=3D"font-family: Arial; =
font-size: 13.3333px; "></O:P></SPAN></FONT></P><P =
class=3D"MsoNormal"><FONT size=3D"2" face=3D"Arial"><SPAN =
style=3D"font-size:10.0pt; font-family:Arial; font-size: 13.3333px; =
"><SPAN class=3D"Apple-style-span" style=3D"font-family: Arial; =
font-size: 13.3333px; ">=A0</SPAN><O:P style=3D"font-family: Arial; =
font-size: 13.3333px; "></O:P></SPAN></FONT></P><P =
class=3D"MsoNormal"><FONT size=3D"2" face=3D"Arial"><SPAN =
style=3D"font-size:10.0pt; font-family:Arial; font-size: 13.3333px; =
"><SPAN class=3D"Apple-style-span" style=3D"font-family: Arial; =
font-size: 13.3333px; ">=A0=A0=A0 Does XORP have support for triggered =
rip extension (rfc 2091). =46rom the documents that I read, it doesn=92t =
look like XORP supports it but just wanted to confirm.</SPAN><O:P =
style=3D"font-family: Arial; font-size: 13.3333px; =
"></O:P></SPAN></FONT></P><P class=3D"MsoNormal"><FONT size=3D"2" =
face=3D"Arial"><SPAN style=3D"font-size:10.0pt; font-family:Arial; =
font-size: 13.3333px; "><O:P style=3D"font-family: Arial; font-size: =
13.3333px; "><SPAN class=3D"Apple-style-span" style=3D"font-family: =
Arial; font-size: 13.3333px; ">=A0</SPAN></O:P></SPAN></FONT></P><P =
class=3D"MsoNormal"><FONT size=3D"2" face=3D"Arial"><SPAN =
style=3D"font-size:10.0pt; font-family:Arial; font-size: 13.3333px; =
"><SPAN class=3D"Apple-style-span" style=3D"font-family: Arial; =
font-size: 13.3333px; ">Thanks,</SPAN><O:P style=3D"font-family: Arial; =
font-size: 13.3333px; "></O:P></SPAN></FONT></P><P =
class=3D"MsoNormal"><FONT size=3D"2" face=3D"Arial"><SPAN =
style=3D"font-size:10.0pt; font-family:Arial; font-size: 13.3333px; =
"><SPAN class=3D"Apple-style-span" style=3D"font-family: Arial; =
font-size: 13.3333px; ">Ambiga</SPAN><O:P style=3D"font-family: Arial; =
font-size: 13.3333px; =
"></O:P></SPAN></FONT></P></DIV></O:SMARTTAGTYPE><BR =
class=3D"Apple-interchange-newline"></SPAN></BLOCKQUOTE></DIV><BR></BODY><=
/HTML>=

--Apple-Mail-85-71208964--


From pavlin@icir.org  Thu Mar 30 22:54:50 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 30 Mar 2006 14:54:50 -0800
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: Message from Kristian Larsson <kristian@juniks.net>
 of "Thu, 30 Mar 2006 15:36:57 +0200." <20060330133656.GC24663@juniks.net>
Message-ID: <200603302254.k2UMsotk044494@possum.icir.org>

> I would like to see #199 commited to CVS and I
> will open up a bug report soon just as I'm sure I
> have looked through all the previous. Don't want
> to create a duplicate.

Your patch for #199 looks good, so I will try to double-test and
commit it relatively soon.

> Anyway my current problem lies in that my
> configuration contains:
>         bgp {
>             bgp-id: 195.182.5.253
>             local-as: 39525
>             peer "217.10.127.13" {
>                 as: 35706
>                 next-hop: 217.10.127.13
>                 local-ip: "217.10.127.14"
>             }
>         }
> but xorp_bgp seems to have crashed.
> I would now like to do a 'commit full' so that bgp
> is restarted. I do not want to loose OSPF
> connectivity (ie, don't restart entire XORP) so
> currently my only solution seems to be to delete
> the bgp part of the configuration and readd it
> again.
> 
> Anyway, as stated I think the commit command
> should be available all the time, as suggest by
> #199.

I agree about #199 alone, but "commit full" just to restart BGP may
be confusing. A command like "restart bgp" or "restart protocols
bgp" might be more intuitive.

Pavlin


From pavlin@icir.org  Fri Mar 31 02:14:00 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 30 Mar 2006 18:14:00 -0800
Subject: [Xorp-hackers] XORT-NAT: Proposal for NAT interface XIF and a config file syntaks
In-Reply-To: Message from Kristen Nielsen <krn@krn.dk>
 of "Mon, 20 Feb 2006 17:58:50 +0100." <43F9F54A.9020909@krn.dk>
Message-ID: <200603310214.k2V2E0pt046265@possum.icir.org>

[Note: a follow-up of an old email that was postponed for discussion
 after the 1.2 release].

> After a long time of considerations and working on specifying a
> configuratoin syntax and a XIF file for a NAT module, I am hereby
> sending this proposal to the list for comments.
> 
> (Re my mail from oct 16 2005 with subject: NAT support for XORP)
> 
> 
> 20060200-NAT-interface-descr.txt file contains the syntax and a few
> samples of use of the configuration format.
> 
> The nat.xif file has kdoc documentation documenting the various
> functions and parameters.
> 
> The idea is to provice a common interface for the NAT module, with a
> defined syntax, and then use either the native (FreeBSD natd/or the
> similar functionality in linux) daemon, or  a click module, with a rule
> of thumb something like this:
> 
> If the nat configuration is possible to implement with the native module
> this can be used, else the user must switch to the click nat module to
> achieve the wanted functionality.

The caveat with the above rule is that the user must have Click.
Currently, kernel-mode Click works only on Linux and some versions
of FreeBSD, and those systems already have native NAT support.
FYI, I believe user-mode Click works on a larger variety of systems
(I have been able to compile and use it as-is on Mac OS X), but
obviously you will get some performance penalty if you perform NAT
in user space Click. The upside of user-space Click NAT of course
would be that you don't have to modify your kernel and the
performance hit may be acceptable in most cases (you may want to do
some measurements here to prove this of course).

> I have designed with the use of IP-realms (aka different ip domains)
> which I am aware of is not possible to use in the standard ip stack of
> Freebsd/Linux, but if one make configurations with non overlapping ip
> ranges it will actually be possible to implement theese in the existing
> kernel / ip stacks. The realm stuff is kept entirely in the nat config
> area of the config file.
> 
> I would apreaciate comments on this, as I would like to continue
> planning and coding soon.
> 
> I would also like to have ideas / comments about how to add more
> datatypes to the idl generator scripts. (for the port type, and an
> eventually ipv4-range type (which I here has made with 2 ipv4 ip-addresses.)

Can you clarify what you mean by "idl generator scripts".

If you need ipv4-range type support, there is rtrmgr template type
named "ipv4range" and "ipv6range" which has the syntax IPADDR..IPADDR.
E.g. see the policy section inside etc/templates/bgp.tp.

Comments continuing below.

> Sincerely
> Mr. Kristen Nielsen
> University of Copenhagen
> Copenhagen
> Denmark
> kristen@diku.dk / krn@krn.dk
> phone +4540466221 (gmt -1)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (FreeBSD)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFD+fVJe7tFxipD00wRApbiAJ9p3KmXx/FN7EUjdmMh7hi0szs4hgCgmTNb
> fzLck6xcwnqSfqA3uYgrphA=
> =wZHj
> -----END PGP SIGNATURE-----
> 
> --------------040204020303010209060700
> Content-Type: text/plain;
>  name="20060220-NAT-interface-descr.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="20060220-NAT-interface-descr.txt"
> 
> * Short description of the config file format for the xorp NAT module.
> * Examples of configurations with alike FreeBSD natd commandline.
> * Syntax of the port statement.
> 
> protocols {
>      nat {
> 	disable {disabled:bool}
> 
>   	nat-realm <text:realm-name> <description: description:txt> {

Currently, the rtrmgr template syntax doesn't support multi-value
statements like the one above. You would have to break it into, say:

        nat-realm <text:realm-name>  {
                description: <description:txt>



> 		interface <ifname> vif <vif-name>  { 
> 			description <description:txt>
> 			default-vif-address: <vif-hw-name:txt>
> 			ip-address: <ip:ipv4>
> 			tag: <tagid:txt>
> 
> 			interface-alias {
> 			description: <description:txt>
> 				alias-address: <ip:ipv4list> /* alt to more interface-alias clauses */
> 				tag: <tagid:txt>
> 			}
> 		}

The interface/vif statements need to be specified separately:
 		interface <ifname> {
                        vif <vif-name>  {
                                ...
                        }
                        ...
                }


Also, note that we don't support a list of addresses, hence you may
want to specify all addresses with multi-value nodes like:

 		interface <ifname> {
                        vif <vif-name>  {
                                address <ip:ipv4> {
                                    description: <description:txt>
                                    tag: <tagid:txt>
                                }
                        }
                        ...
                }


> 		
> 		/* Address pool maps to the create/delete/get_nat_realm4 function) */
> 		address-pool {
> 			description: <description:txt>
> 			ip-address: <ip:ipv4>
> 			ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 			ipnet: <ipnet:ipv4net>
> 			tag:  <tag:txt>
> 		}
> 	}
> 
> 	static-nat {
> 		map {
> 			description: <description:txt>
> 			source { 
> 				realm: <srcrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 			destination {
> 				realm: <destrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 		}
> 	}
> 
> 	dynamic-nat {
> 		map {
> 			description: <description:txt>
> 			source { 
> 				realm: <srcrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 			destination {
> 				realm: <destrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 				binding: <binding:txt>
> 
> 			}
> 		}
> 
> 	ls-nat {
> 		map {
> 			description: <description:txt>
> 			source { 
> 				realm: <srcrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 			destination {
> 				realm: <destrealm:txt>
> 				ip-address: <ip:ipv4>
> 				ip-range: <ipfrom:ipv4> - <ipto:ipv4>
> 				ipnet: <ipnet:ipv4net>
> 				tag:  <tag:txt>
> 				port: <ports:ipv4ports>
> 			}
> 		}
> 	}
>      }
> }
> 
> 
> The "port:" parameter is used to set the ports in use for an actual translation.
> Syntax:
> 
> <ports-stmt> ::= ports: <port-def>
> <ports-def> ::= <protocol> <port-list>
> <port-list> ::=  <port-spec> [, <port-def>]...
> <port-spec> ::= <port-nr | service-name> | <port-range | service-name-range>
> <protocol> ::= tcp | udp
> <port-nr> ::=  <digits>
> service-name ::= <letters><letters|digits>...
> digits ::= <digit>...
> digit ::= <0|1|2|3|4|5|6|7|8|9>
> letters ::= <letter>...
> letter ::=<a...z|A..Z>
> 
> Example:
> 
> ports: tcp 22,33,44-55, udp 22,33,66-77, 88


The above syntax seems to me as tcp/udp centric and assumes the
particular protocol has the concept of a port.
This is not true for protocols like ICMP and GRE.


> Sample configurations with similar FreeBSD natd mappings.
> 
> The FreeBSD 
> 
> "natd -redirect_port tcp 172.17.16.15/telnet 6666" 
> 
> command with the global ip address equal to 80.10.10.10 is expressed in XORP NAT configuration files as:
> 
> protocols {
> 	NAT {
> 		realm "global" {
> 			ip: 80.10.1010
> 		}
> 		
> 		realm "local" {
> 			ip: 172.17.16.15	
> 		}
> 		static-map { <description> 
> 			source { ip-address: 80.10.10.10
> 				  ports: tcp 6666
> 			}
> 
> 			destination {
> 				ip-address: 172.17.16.15
> 				ports: tcp telnet
> 			}
> 		}
> 	}
> }        


I would recommend to generalize the source and destination syntax by
separating the concept of protocol and port. Of course, for
protocols like tcp and udp you must have ports, so your syntax must
incorporate that too :)


> The configline: 
> "natd -interface em0"
> Creation of a dynamic mapping from 172.17.16/24 to global address of em0 interface = ip 80.10.10.10 is expressed as:
> 
> protocols {
> 	NAT{
> 		realm "global" {
> 			ip: 80.10.10.10
> 			tag "globalip"
> 		}
> 		
> 		realm "local" {
> 			ipnet: 172.17.16.0/24
> 			tag: "localnet"}	
> 
> 		dynamic-map { <description> 
> 			source {tag: "localnet"
> 			}
> 			destination {
> 				tag: "globalip"
> 			}
> 		}
> 	}
> }        
> Written by 
> Kristen Nielsen
> Computer Science dept
> University of Copenhagen, Denmark
> kristen@diku.dk / KrN@KrN.dk
> 
> 
> 
> --------------040204020303010209060700
> Content-Type: text/plain;
>  name="nat.xif"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="nat.xif"
> 
> /* xorp/xrl/interfaces/nat.xif file by KrN@KrN.DK 20060220 */
> /* Suggestion to a nat interface for xorp. */
> 
> 
> /* The following interfaces exists for the xorp nat module */
> 
> 	/**
> 	 * Network address translation (NAT) interface.
> 	 * The NAT module consists of the following configuration elements:
> 	 *
> 	 * set_nat_disable and get_nat_disable:
> 	 * 	sets and returns the status of the nat module
> 	 *
>  	 * nat_realm: 
> 	 *	Manages (creates/deletes/get) realms for use in nat mappings.
> 	 *	Before realms can be used in configurations, they must 
> 	 * 	be created.
> 	 *	
> 	 * nat_realm_vif4:
> 	 *	Manages (creates/delete/lists) vif addresses for nat use 
> 	 * 	in nat mappings.
> 	 *
> 	 * nat_realm_alias4:
> 	 *	Manages (creates/deletes/lists) alias ipv4 addresses for vif 
> 	 * 	interfaces for use in nat mappings.
> 	 *
> 	 * nat_realm4:
> 	 *	Defines ip4 addresses, ip4 networks and ip4 address ranges 
> 	 * 	for use in nat mappings. Addresses are not directly connected 
> 	 * 	to any vif on the xorp router. Addresses are reachable 
> 	 * 	via the realm / vif interface stated. (This will probably be
> 	 *	changed to be the interface pointed out by the next-hop entry
> 	 * 	in the rib.)
> 	 *
> 	 * nat_static_map4: 
> 	 *	Defines static NAT table mappings
> 	 *	From the realm and ip definitions in the nat_realm_* group
> 	 *	Tcp and/or udp port definitions can be defined here.
> 	 *
> 	 * nat_dynamic_map4: 
> 	 *	Defines dynamic NAT table mappings (triggers)
> 	 *	From the definitions in the nat_real_* group
> 	 *	Tcp and/or udp port definitions can be defined here.
> 	 *
> 	 * nat_lsnat_map4: 
> 	 *	Defines Load Sharing NAT mappings
> 	 *	From the definitions in the nat_real_* group
> 	 *	Tcp and/or udp port definitions can be defined here.
> 	 *
> 	 */
> interface nat/0.1 {
> 
> 	/** 
> 	 * set nat disable (and enable) function
> 	 *
> 	 * @param disabled sets the status of the nat module true = disabled, 
> 	 * false = enabled
> 	 * @param disabledstatus returns the status of the module, 
> 	 * true = disabled, false = enabled
> 	 */
> 	set_nat_disable		? disabled:bool -> disabledstatus:bool

What is the purpose of the returned disabledstatus?
If "set_nat_disable" returned success, then the status must be same
as the "disabled:bool" argument when the XRL was invoked.
BTW, stylistically, we prefer that longer names are separated
with, say, underscore: disabledstatus -> disabled_status :)

This is my last comment. Without going into details, the rest of the
XRLs seem reasonable. Though, if you change the NAT configuration
syntax quite likely you would have to change some of the XRLs as
well.

Pavlin


> 	/** 
> 	 * get nat status function
> 	 *
> 	 * @param disabledstatus returns the status of the module, (as the 
> 	 * set_nat_disable function)  true = disabled, false = enabled
> 	 */
> 	get_nat_disable		-> disabledstatus:bool
> 
> 
> 	/** 
> 	 * create_nat_realm - creates a nat realm.
> 	 *
> 	 * @param realm holds the name of the realm to be created. The name 
> 	 * must not exist when the call is made.
> 	 * @param descr is the textual description of the realm.
> 	 */
> 	create_nat_realm	? realm:txt & descr:txt
> 	
> 	/** 
> 	 * delete_nat_realm - deletes a nat realm.
> 	 *
> 	 * @param realm holds the name of the realm to be deleted. The name 
> 	 * must exist when the call is made.
> 	 */
>         delete_nat_realm 	? realm:txt
> 	
> 	/** 
> 	 * get_nat_realm - lists nat realms.
> 	 *
> 	 * @param realm holds the name of the realm to be deleted. 
> 	 * If the parameter is NULL, all existing realms is returned.
> 	 */
>         get_nat_realm	 	? realm:txt -> realms:list 
> 
> 
> 	/** 
> 	 * create_nat_realm_vif4 - creates an entry for the base ipv4 address 
> 	 * of a virtual interface. 
> 	 * Any virtual interface can at most be a member of one realm. 
> 	 * Virtual interfaces must be in the same realm as the ip addresses
> 	 * passing the vif interface.
> 	 * 
> 	 * @param realm is an existing realm that the vif is mapped to.
> 	 * @param ifname is the name of the physical interface where the 
> 	 * vif is defined.
> 	 * @param vifname is the name of the virtual interface to be mapped.
> 	 * @param tag is a textlabel that the mapping is labeled with.
> 	 * @param description textual description of the mapping.
> 	 */
> 	create_nat_realm_vif4 	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt & description:txt 
> 
> 	/** 
> 	 * delete_nat_realm_vif4 - removes an entry for a base ipv4 (vif) 
> 	 * address of virtual interface from a nat realm.
> 	 * The definitions matching all the supplied parameters is deleted.
> 	 * Wild card parameters must be set to NULL.
> 	 *
> 	 * @param realm all vif4 definitions to this realm is deleted.
> 	 * @param ifname all definitions with this ifname is deleted. 
> 	 * @param vifname all mappings to this vifname is deleted
> 	 * @param tag all mappings with this tag is deleted.
> 	 */
> 	delete_nat_realm_vif4	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt
> 
> 	/**
> 	 * update_nat_realm_vif4 - updates an existing vif mapping with its
> 	 * new ipv4 address. 
> 	 * The vif4 mapping is updated when the vif get a new ipv4 address.
> 	 */
> 	update_nat_realm_vif4 	? ifname:txt & vifname:txt & ip:ipv4
> 	 
> 	/** 
> 	 * get_nat_realm_vif4 - lists nat_realm_vif4 definitions.
> 	 *
> 	 * get_nat_realm_vif4 returns a list of all nat_realm_vif4 
> 	 * interfaces in the router matching the realm supplied. 
> 	 * @param realm specifies the realm to return interfaces for. 
> 	 * If NULL then all defined nat_realm_vif4 interfaces are returned.
> 	 */
> 	get_nat_realm_vif4 	? realm:txt -> nat_realm_vif4s:list
> 
> 	
> 	/** 
> 	 * create_nat_realm_alias4 - creates a mapping to the nat_realm 
> 	 * definitions. Manipulates ipv4 address aliases of an interface 
> 	 * (vif) for in/out going nat gateways. Aliases are not the base 
> 	 * ipv4 address of the virtual interface, but ipv4 addresses in 
> 	 * the same subnet as the vif. (see nat_realm_vif)
> 	 *
> 	 * Any aliases, aliased to a vif must be in the same realm as the 
> 	 * vif itself.
> 	 *
> 	 * @param realm specifies the realm that the IP address belongs to.
> 	 * @param ifname is the physical interfaces for this interface
> 	 * @param vifname is the virtual interface name to add this alias to.
> 	 * @param tag is a label for grouping definitions.
> 	 * @param description is a textual description of this alias.
> 	 * @param ipaddr is the ipv4 alias address added to the vif.
> 	 */
> 	create_nat_realm_alias4	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt & description:txt & ipaddr:ipv4
> 
> 
> 	/** 
> 	 * delete_realm_alias4 function
> 	 * Deletes ipv4 realm_alias4 address from the virtuel interface (vif). 
> 	 *
> 	 * The alias4 mappings matching the supplied parameters are deleted.
> 	 * Parameters that are not defined (=not matched against) must be NULL. 
> 	 *
> 	 * @param realm the alias4 mappings in the same realm is deleted.
> 	 * @param ifname all alias4 mappings defined for this interface is
> 	 * deleted.
> 	 * @param vifname all alias4 mappings defined under this vif is 
> 	 * deleted.
> 	 * @param tag all alias4 mappings with tag is deleted.
> 	 * @param ipaddr the alias4 mapping with this ipv4 address is deleted.
> 	 */
> 	delete_nat_realm_alias4	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt & ipaddr:ipv4
> 
> 	/**
> 	 * get_nat_realm_alias4 returns a nat_realm_alias4 list with matching 
> 	 * alias4 elements. Wildcard parameters shuld be set to NULL.
> 	 *
> 	 * @param realm specifies the realm of the alias4 addresses to be 
> 	 * returned.
> 	 * @param ifname specifies the physical interfaces to match.
> 	 * @param vifname specifies the virtual interfaces to match.
> 	 * @param tag specifies the tag of the definitions to match.
> 	 * @param ipaddr specifies the ipv4 addr of the alias4 to match.
> 	 * @param nat_realm_alias4s is the list of the matching aliases 
> 	 * defined.
> 	 */
> 	get_nat_realm_alias4	? realm:txt & ifname:txt & vifname:txt & \
> 				tag:txt & ipaddr:ipv4 \
> 				-> nat_realm_alias4s:list
> 
> 	/** 
> 	 * create_nat_realm - create definitions of ipv4 addresses/ipv4/
> 	 * networks/ipv4 ip ranges to the nat_realm list.
> 	 *
> 	 * The ipv4 addresses / ipv4 networks / ipv4 address ranges / tagged
> 	 * list of definitions, are all ip-addresses not directly attached
> 	 * to any physical/virtual interface on the xorp router.
> 	 * 
> 	 * The function have the following way of interpreting the address 
> 	 * arguments:
> 	 * All function calls must have theese parameters defined: 
> 	 * <realm> <ifname> <vifname>, where realm specifies the actural realm.
> 	 * ifname and vifname the interfaces to route these addresses through.
> 	 * (If the ifname and vifname is possible to acquire via the routing
> 	 * info, these parameters might disappear during implementation) 
> 	 *
> 	 * To specify a tag for the definition, supply the <tag> parameter.
> 	 *
> 	 * To specify an single ipv4 address supply ONLY the <ip> parameter. 
> 	 *
> 	 * To specify an ipv4 network supply ONLY the <ipnet> parameter. 
> 	 *
> 	 * To specify an ipv4 range supply ONLY the <ip> and <ipto> parameters. 
> 	 * <ip> is the lowest ip address and ipto is the highest ip address
> 	 * in the range.
> 	 * 
> 	 * The 3 types of definitions above can not be mixed in a single call
> 	 * to the function. Grouping is done with defining more of the 3
> 	 * first classes with the same tag.
> 	 * 
> 	 * create_nat_realm4 create an ipv4 address/ipv4network/ipv4-range/tag
> 	 * at the nat map list.
> 	 *
> 	 * @param realm specifies the realm to which the mapping belong.
> 	 * @param tag maps the definition with this tag.
> 	 * @param description a textual description of this alias.
> 	 * @param ip is the ip address or the lowest bound of an ip range.
> 	 * @param ipto is the highest bound of a range.
> 	 * @param ipnet specifies an ipv4 network (ip address + subnetmask)
> 	 */
> 	create_nat_realm4	 	? realm:txt & \
> 					tag:txt & description:txt & \
> 					ip:ipv4 & ipto:ipv4 & \
> 					ipnet:ipv4net
> 
> 	/**
> 	 * delete_nat_realm4 deletes all nat_realm4 mappings, matching
> 	 * all supplied parameters. Wild card parameters must be set to NULL.
> 	 * (For further doc see add_nat_realm4)
> 	 *
> 	 * @param realm all nat_realm4 with this realm is deleted.
> 	 * @param tag all nat_realm4 definitions with this tag is deleted.
> 	 * @param ip the ipv4 address mapping is deleted. (see ipto param too)
> 	 * @param ipto the range defined together with the ip parameter is 
> 	 * deleted.
> 	 * @param ipnet the ipv4network defined is deleted.
> 	 * 
> 	 * If more parameters are defined, only the definitions that match 
> 	 * ALL the supplied parameters is deleted. 
> 	 */
> 	delete_nat_realm4 		? realm:txt & \
> 					tag:txt & \
> 					ip:ipv4 & ipto:ipv4 & \
> 					ipnet:ipv4net
> 
> 	/**
> 	 * get_nat_realm4 function - returns the list of defined elements 
> 	 * that matches the supplied parameters.
> 	 * (For further doc on the use see add_nat_realm4 the doc.)
> 	 * Wildcard parameters must be set to NULL.
> 	 *
> 	 * @param realm returns the list of realm4 definitions for this realm.
> 	 * @param tag returns the list of definitions tagged with this tag.
> 	 * @param ip returns the list of definitions with this ipv4 address.
> 	 * @param ipto returns the list of definitions with this ipv4 range. 
> 	 * @param ipnet returns the list of ipv4 networks defined.
> 	 * @param nat_realm4s is a list of the matched definitions.
> 	 */
> 	get_nat_realm4 			? realm:txt & \
> 					tag:txt & description:txt & \
> 					ip:ipv4 & ipto:ipv4 & \
> 					ipnet:ipv4net -> nat_realm4s:list
> 
> 	/**
> 	 * create_nat_static_map4
> 	 *
> 	 * create_nat_static_map4 - defines static NAT table entries from the 
> 	 * ip definitions from the nat_realm* functions.
> 	 *
> 	 * The nat_static_map functions defines static nat mappings between 
> 	 * ip addresses at the source side realm and the ip addresses of 
> 	 * the destination side realm.
> 	 * If the ip sizes of the ranges on either side of the mapping is not 
> 	 * equal, then the mappings must go from the source side realm 
> 	 * (aka local realm) to the destination side realm (aka global realm).
> 	 * ip addresses that is used for TCP/UDP port mapping 
> 	 * (port overloading) must always be defined at the destination side.
> 	 *
> 	 * The nat_static_map function has more sub functions dependent of 
> 	 * the supplied parameters. The parameters can define either a single
> 	 * ip address, a contiguous range of ip addresses or a sub net, or a
> 	 * tagged set of definitions. The ip addresses and realm used in a map 
> 	 * statement must be defined in a nat_realm* clause.
> 	 * The source and destination side of a mapping can take all 4 forms
> 	 * from the following definitions.
> 	 *  
> 	 * To specify a single ip address the ip parameter is used. The 
> 	 * ipto paramter must be NULL.
> 	 * 
> 	 * To specify a contiguous range of IP addresses, the ip and ipto 
> 	 * parameters are used. The ipnet parameter must be NULL.
> 	 * 
> 	 * To specify an ipnetwork, the ipnet parameters must be specified. 
> 	 * The ipnet takes a subnet-address and a submet-mask. The ip and ipto
> 	 * parameters must be NULL.
> 	 * 
> 	 * To use a tag from the nat_realm definitions, specify the tag at 
> 	 * the tag parameter. The ip, ipto and ipnet parameters must be NULL.
> 	 *
> 	 * @param srcrealm specifies the realm for the source side of the map.
> 	 *
> 	 * @param destrealm specifies the realm for the destination side 
> 	 * of the map.
> 	 *
> 	 * @param srcip is the ipv4 source ip address of a mapping.
> 	 *
> 	 * @param srcipto is the source ipv4 address that forms the upper 
> 	 * bound of an ip range.
> 	 *
> 	 * @param srcipnet is the ipv4 network which forms the source mapping.
> 	 * bound of an ip range.
> 	 *
> 	 * @param srctag maps all nat_realm definitions with the same tag as
> 	 * the source definition.
> 	 *
> 	 * @param srcport is the range of ports used to this mapping.
> 	 *
> 	 * @param destip is the ipv4 destination address of the mapping
> 	 *
> 	 * @param destipto is the ipv4 address that forms the upper bound of 
> 	 * the destination ip range. 
> 	 *
> 	 * @param destipnet is the ipv4 network that is the destination ip 
> 	 * addresses for the mapping.
> 	 *
> 	 * @param desttag maps all nat_realm definitions with the same tag as
> 	 * the destination definition.
>  	 *
> 	 * @param destport is a list of tcp and/or udp ports used at the
> 	 * destination addresses.
> 	 *
> 	 */
> 	create_nat_static_map4		? description:txt & \
> 					srcrealm:txt & \
> 					srcip:ipv4 & srcipto:ipv4 & \
> 					srcipnet:ipv4net & \
> 					srctag:txt & \
> 					srcport:ipv4ports & \
> 					destrealm:txt & \
> 					destip:ipv4 & destipto:ipv4 & \
> 					destipnet:ipv4net & \
> 					desttag:txt & \
> 					destport:ipv4ports
> 
> 	/**
> 	 * delete_nat_static_map4
> 	 *
> 	 * delete_nat_static_map4 - delete static nat table entries from the 
> 	 * ip definitions from the nat_static_map4 functions.
> 	 *
> 	 * The function deletes the nat_static_map4 entries that matches
> 	 * all the supplied parameters.  (for more information about the 
> 	 * interfaces see create_nat_static_map4 documentation)
> 	 *
> 	 * The selected ranges must be fully matching sets from the
> 	 * create_nat_static_map4 definition. No internal ranges can be deleted.
> 	 *
> 	 * @param srcrealm specifies the source realm to be deleted. All 
> 	 * nat_static_map4 definitions with the same realm is selected.
> 	 *
> 	 * @param destrealm specifies the realm for the destination side 
> 	 * to be deleted. All nat_static_map4 definitions with the same realm 
> 	 * is selected.
> 	 *
> 	 * @param srcip is the ipv4 source ip address to be deleted.
> 	 *
> 	 * @param srcipto is together with the srcip parameter defines the
> 	 * source ip range to be deleted. 
> 	 *
> 	 * @param srcipnet is the ipv4 network source mapping to be deleted.
> 	 *
> 	 * @param srctag maps selects the source tags to be deleted.
> 	 * 
> 	 * @param srcport is the range of tcp and/or udp ports to be deleted.
> 	 *
> 	 * @param destip is the ipv4 destination address to be deleted.
> 	 *
> 	 * @param destipto is together with the destip parameter defines 
> 	 * the destination ip range to be deleted.
> 	 *
> 	 * @param destipnet is the ipv4 network to be deleted.
> 	 *
> 	 * @param desttag maps defines the destination tags to be deleted.
> 	 *
> 	 * @param destport is a list of tcp and/or udp ports to be deleted.
> 	 */
> 	delete_nat_static_map4		? srcrealm:txt & \
> 					srcip:ipv4 & srcipto:ipv4 & \
> 					srcipnet:ipv4net & \
> 					srctag:txt & \
> 					srcport:ipv4ports & \
> 					destrealm:txt & \
> 					destip:ipv4 & destipto:ipv4 & \
> 					destipnet:ipv4net & \
> 					desttag:txt & \
> 					destport:ipv4ports
> 
> 	/**
> 	 * get_nat_static_map4 - lists nat_static_map4 entries.
> 	 *
> 	 * get_nat_static_map4 - lists static NAT table entries that matches 
> 	 * the supplied parameters.
> 	 *
> 	 * The function deletes the nat_static_map4 entries that is matches
> 	 * all the supplied parameters.
> 	 * (for more information about the interfaces see 
> 	 * create_nat_static_map4 documentation)
> 	 *
> 	 * @param srcrealm specifies the source realm to be listed.
> 	 *
> 	 * @param destrealm specifies the realm for the destination side 
> 	 * to be listed.
> 	 *
> 	 * @param srcip is the ipv4 source ip address to be listed.
> 	 *
> 	 * @param srcipto is together with the srcip parameter defines the
> 	 * source ip range to be listed. 
> 	 *
> 	 * @param srcipnet is the ipv4 network source to be listed.
> 	 *
> 	 * @param srctag maps selects the srctags to be listed.
> 	 *
> 	 * @param srcport is the range of tcp and/or udp ports to be delted.
> 	 *
> 	 * @param destip is the ipv4 destination address to be listed.
> 	 *
> 	 * @param destipto is together with the destip parameter defines 
> 	 * the destination ip range to be listed.
> 	 *
> 	 * @param destipnet is the ipv4 network to be listed.
> 	 *
> 	 * @param desttag maps defines the destination tags to be listed.
> 	 *
> 	 * @param nat_static_map4s contains the list of matched elements.
> 	 *
> 	 * @param destport is a list of tcp and/or udp ports to be matched.
> 	 */
> 	get_nat_static_map4	? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				destport:ipv4ports & \
> 				desttag:txt -> nat_static_map4s:list
> 
> 
> 	/** 
> 	 * create_nat_dynamic map definitions.
> 	 *
> 	 * The nat_static_map functions defines static mappings between 
> 	 * IP addresses at the source side realm and the IP addresses of 
> 	 * the destination side realm.
> 	 * If the IP sizes of the ranges on either side is not equal, 
> 	 * then the mappings must go from the source side realm 
> 	 * (aka local realm) and the destination side realm (aka global realm).
> 	 * IP addresses that is used for TCP/UDP port mapping 
> 	 * (port overloading) must be defined on the destination side.
> 	 *
> 	 * @param srcrealm specify the network realm for the source part
> 	 * of the mapping.
> 	 *
> 	 * @param srctag maps the nat_realm* definitions with this tag as
> 	 * the source side of the mapping. The tagged definitions must belong
> 	 * to the same realm as stated in srcrealm. If the special meaning
> 	 * tag "all" is given then all the definitions in the nat_realm 
> 	 * with the same realm as stated in srcrealm is matched.
> 	 *
> 	 * Src or dest definitions defults to "all" which is all addresses 
> 	 * in the matching (src/dest) realm as defined in nat_realm_* group.
> 	 *
> 	 * @param srcip is the ipv4 source ip address of a mapping.
> 	 *
> 	 * @param srcipnet is the ipv4 network which forms the source mapping.
> 	 *
> 	 * @param scrip is the source ipv4 address that forms the lower bound 
> 	 * of an ip range.
> 	 *
> 	 * @param srcipto is the source ipv4 address that forms the upper 
> 	 * bound of an ip range.
> 	 *
> 	 * @param srcport is the range of tcp and/or udp ports to be used in
> 	 * the mapping.
> 	 *
> 	 * @param destip is the ipv4 destination address of the mapping
> 	 *
> 	 * @param destipnet is the ipv4 network that is the destination ip 
> 	 * addresses for the mapping.
> 	 *
> 	 * @param destip is the ipv4 address that forms the lower bound of the 
> 	 * destination ip range.
> 	 *
> 	 * @param destipto is the ipv4 address that forms the upper bound of 
> 	 * the destination ip range. 
> 	 *
> 	 * @param desttag maps the nat_realm* definitions with this tag as
> 	 * the destination side of the mapping. The tagged definitions must 
> 	 * belong to the same realm as stated in srcrealm. If the special 
> 	 * meaning tag "all" is given then all the definitions in the nat_realm 
> 	 * with the same realm as stated in srcrealm is matched.
> 	 * 
> 	 * @param destport is a list of tcp and/or udp ports to use for the
> 	 * dynamic mapping.
> 	 *
> 	 * @param binding This argument can be "dynamic" (default) or "fixed"
> 	 * Dynamic can be a new mapping each time the mapping is used for a 
> 	 * new connection (from src side). "fixed" is using the same source 
> 	 * and destination mapping each time the src ip/port is connecting.
> 	 */
> 	create_nat_dynamic_map4	? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				binding:txt
> 
> 	/** 
> 	 * delete_nat_dynamic_map4
> 	 * 
> 	 * The delete_nat_dynamic_map4 function deletes the elements from the
> 	 * nat_dynamic_map4 table that matches the supplied parameters.
> 	 *
> 	 * @param srcrealm matches source realm parameter of mappings.
> 	 *
> 	 * @param srctag matches the source tag paramter of the mappings to 
> 	 * be deleted.
> 	 * If the special meaning tag "all" is given then all the definitions 
> 	 * with this tag on the source side is matched. With the same realm 
> 	 * as stated in srcrealm is matched.
> 	 *
> 	 * @param srcip matches the ipv4 source ip, or the lower bound of an
> 	 * ipv4 ip-range to be deleted.
> 	 *
> 	 * @param srcipto matches the source ipv4 address that forms the upper 
> 	 * bound of an ip range to be deleted.
> 	 *
> 	 * @param srcipnet matches the source ipv4 network to be deleted.
> 	 * 
> 	 * @param srcport is the tcp and/or udp port range to be deleted.
> 	 *
> 	 * @param destip matches the ipv4 destination address of the mapping
> 	 * or the ipv4 address that forms the lower bound of the destination
> 	 * ip range.
> 	 *
> 	 * @param destipto matches the destination ipv4 address to be deleted.
> 	 *
> 	 * @param destipnet matches the destination ipv4 network.
> 	 *
> 	 * @param desttag maps the mappings with this tag as the destination 
> 	 * side of the mapping. The tagged definitions must belong to the
> 	 * same realm as stated in srcrealm. If the special 
> 	 * meaning tag "all" is given then all the definitions in the 
> 	 * nat_dynamic_realm with the same source realm as stated in srcrealm 
> 	 * is matched.
> 	 * 
> 	 * @param destport is a list of tcp and/or udp ports to be deleted.
> 	 *
> 	 * @param binding This argument can be "dynamic" (default) or "fixed"
> 	 * Dynamic can be a new mapping each time the mapping is used for a 
> 	 * new connection (from src side). "fixed" is using the same source 
> 	 * and destination mapping each time the src ip/port is connecting.
> 	 */
> 	delete_nat_dynamic_map4	? srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				binding:txt
> 
> 	/** 
> 	 * get_nat_dynamic_map4
> 	 * 
> 	 * The get_nat_dynamic_map4 function returns the elements from the
> 	 * nat_dynamic_map4 table that matches all the supplied parameters.
> 	 *
> 	 * @param srcrealm matches source realm parameter of the mappings.
> 	 *
> 	 * @param srctag matches the source tag parameter of the mappings.
> 	 * If the special meaning tag "all" is given then all the definitions 
> 	 * with this tag on the source side is matched. With the same realm 
> 	 * as stated in srcrealm is matched.
> 	 *
> 	 * @param srcip matches the ipv4 source ip, or the lower bound of an
> 	 * ipv4 ip-range.
> 	 *
> 	 * @param srcipto matches the source ipv4 address that forms the upper 
> 	 * bound of an ip range.
> 	 *
> 	 * @param srcipnet matches the source ipv4 network.
> 	 * 
> 	 * @param srcport is the tcp and/or udp range to be returned.
> 	 *
> 	 * @param destip matches the ipv4 destination address of the mapping
> 	 * or the ipv4 address that forms the lower bound of the destination
> 	 * ip range.
> 	 *
> 	 * @param destipto matches the destination ipv4 address.
> 	 *
> 	 * @param destipnet matches the destination ipv4 network.
> 	 *
> 	 * @param desttag maps the mappings with this tag as the destination 
> 	 * side of the mapping. The tagged definitions must belong to the
> 	 * same realm as stated in srcrealm. If the special 
> 	 * mening tag "all" is given then all the definitions in the 
> 	 * nat_dynamic_realm with the same source realm as stated in srcrealm 
> 	 * is matched.
> 	 *
> 	 * @param destport is a list of tcp and/or udp ports to be returned.
> 	 *
> 	 * @param binding This argument can be "dynamic" (default) or "fixed"
> 	 * Dynamic can be a new mapping each time the mapping is used for a 
> 	 * new connection (from src side). "fixed" is using the same source 
> 	 * and destination mapping each time the src ip/port is connecting.
> 	 */
> 	get_nat_dynamic_map4	? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				binding:txt -> nat_dynamic_map4s:list
> 
> 
> 
> 	/** 
> 	 * lsnat_map functions - define Load Sharing NAT (LSNAT) functionality.
> 	 *  
> 	 * lsnat_map defines hosts at the destination side which is to be
> 	 * loadshared when accesses via a common global address and port, 
> 	 * defined at the source side.
> 	 *
> 	 * The lsnat_map function has a range of ways to define ipv4 addresses,
> 	 * ipv4 networks and ipv4 ip address ranges.
> 	 * The parameters can define either a single ip address, a contigous 
> 	 * range of IP addresses or a subnet, or a tag.
> 	 * The source and destination side of a mapping can each take all 
> 	 * 4 forms.
> 	 *  
> 	 * To specify an single ip address the ip parameter is used. The 
> 	 * ipto paramter must be NULL.
> 	 * 
> 	 * To specify a contiguous range of IP addresses, the ip and ipto 
> 	 * parameters are used. The ipnet parameter must be NULL.
> 	 * 
> 	 * To specify an ipnetwork, the ipnet parameters must be specified. 
> 	 * The ipnet takes a sub net-address and a sub net-mask. The ip and ipto
> 	 * parameters must be NULL.
> 	 * 
> 	 * To use a named tag from the nat_realm definitions, specify the tag 
> 	 * at the tag parameter. The ip, ipto and ipnet parameters must be 
> 	 * NULL. Tags with the special value "all" matches all defined 
> 	 * addresses in the same realm as the tag.
> 	 *
> 	 * @param srcrealm defines which realm the source addresses belongs 
> 	 * to. The common ip addresses to access the load shared services must
> 	 * be load shared must be connected to the source side of the map. 
> 	 *
> 	 * @param destrealm defines which realm the destination addresses  
> 	 * belongs to (host network realm). The ip addresses of the hosts
> 	 * with the services to be load shared is on this realm.
> 	 *
> 	 * @param srcip is the ipv4 source ip address of a mapping.
> 	 *
> 	 * @param srcipto is the source ipv4 address that forms the upper 
> 	 * bound of an ip range.
> 	 *
> 	 * @param srcipnet is the ipv4 network which forms the source mapping.
> 	 * bound of an ip range.
> 	 *
> 	 * @param srctag maps all nat_realm definitions with the same tag as
> 	 * the source definition. The special tag value "all" matches all 
> 	 * definitions from the nat_realm with the same realm.
> 	 *
> 	 * @param srcport is the list of tcp and/or udp ports to created.
> 	 *
> 	 * @param destip is the ipv4 destination address of the mapping
> 	 *
> 	 * @param destipto is the ipv4 address that forms the upper bound of 
> 	 * the destination ip range. 
> 	 *
> 	 * @param destipnet is the ipv4 network that is the destination ip 
> 	 * addresses for the mapping.
> 	 *
> 	 * @param desttag maps all nat_realm definitions with the same tag as
> 	 * the destination definition. The special tag value "all" matches all 
> 	 * definitions from the nat_realm with the same realm.
> 	 *
> 	 * @param destport is the tcp and/or udp port to load share.
> 	 *
> 	 * @param lsalgorithm defines the load sharing algorithm, and takes 
> 	 * the values: round-robin, random, (more ?), ...
> 	 *
> 	 */
> 
> 	/**
> 	 * create_lsnat_map4 function -
> 	 * Creates a lsnat_map4 table entry to the nat mappings.
> 	 */
> 	create_lsnat_map4	? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				lsalgorithm:txt
> 
> 	/**
> 	 * delete_lsnat_map4 function -
> 	 * Deletes the lsnat_map4 tableentries from the nat mappings that
> 	 * matches all the defined parameters.
> 	 */
> 	delete_lsnat_map4	? srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 
> 	/**
> 	 * get_lsnat_map4 function -
> 	 * Lists lsnat_map4 table entries that matches all the defined the
> 	 * parameters. 
> 	 */
> 	get_lsnat_map4		? description:txt & \
> 				srcrealm:txt & \
> 				srcip:ipv4 & srcipto:ipv4 & \
> 				srcipnet:ipv4net & \
> 				srctag:txt & \
> 				srcport:ipv4ports & \
> 				destrealm:txt & \
> 				destip:ipv4 & destipto:ipv4 & \
> 				destipnet:ipv4net & \
> 				desttag:txt & \
> 				destport:ipv4ports & \
> 				lsalgorithm:txt -> lsnat_map4s:list
> }
> 
> 
> 
> --------------040204020303010209060700--
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From pavlin@icir.org  Fri Mar 31 06:28:30 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 30 Mar 2006 22:28:30 -0800
Subject: [Xorp-hackers] Old bug entries
In-Reply-To: Message from Pavlin Radoslavov <pavlin@icir.org>
 of "Mon, 20 Mar 2006 15:04:39 PST." <200603202304.k2KN4di6033659@possum.icir.org>
Message-ID: <200603310628.k2V6SUk8048197@possum.icir.org>

<DEL>
> > I meant especially patches in bugzilla entries #463 and #464. But also 
> > #372 and #516. And I'd be really glad if someone can take a look at #574 
> > as well, some of these are really obvious problems.

<DEL>

> With regard to #463 and #464 I started working on them before the
> release, but in the process of integrating the patch I came across
> a section that needed more careful testing. Such testing was going

Hasso,

Just for the record, your original patches were perfectly fine,
and now they are in the CVS. The problem I suspected originally
turned out to be a Linux kernel bug (already fixed in more recent
releases).

The best part of your patches was that you also fixed the Linux
netlink(7) manual page so eventually other developers would not
repeat the mistakes we did!

Sincere "Thank You!" for all your hard work and dedication!

Pavlin