Re: as numbers

[william(at)elan.net]

On Tue, 2 Aug 2005, Geoff Huston wrote:

There is a draft  draft-ietf-idr-as4bytes-10.txt- it is a draft because 
under the current IETF procedures there needs to be 2 independent 
implementations of the specification, and at the moment only Redback's 
BGP has implemented this. Once there is a 2nd implementation it will 
enter the Internet Standards track as a Draft Standard.


There is such as thing as "Proposed Standard" ...

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: as numbers

[Geoff Huston]

At 08:15 PM 1/08/2005, Stephen J. Wilcox wrote:

On Sun, 31 Jul 2005, Geoff Huston wrote:

> So - to NANOG at large - if you want your vendor to include 4-Byte AS 
support
> in their BGP code anytime soon, in order to avoid some last minute 
panic in a
> couple of years hence, then it would appear that you should talk to 
them now

> and say clearly that you want 4-Byte AS support in your BGP software right
> now.

Geoff, excellent idea..

before I forward this email to my suppliers tho, is there a reference I can
send.. excuse my ignorance but I'm not familiar with research done on 4-byte
ASNs, is there a proposed standard implementation?


There is a draft  draft-ietf-idr-as4bytes-10.txt- it is a draft because 
under the current
IETF procedures there needs to be 2 independent implementations of the 
specification,

and at the moment only Redback's BGP has implemented this. Once there is a 2nd
implementation it will enter the Internet Standards track as a Draft Standard.




If I have something definite to request I will immediately send those emails,



http://www.potaroo.net/ispcol/2005-08/as.html

contains the analysis of the AS number consumption data

  regards,

Geoff

Re: as numbers

[Joe Abley]

On 1 Aug 2005, at 06:15, Stephen J. Wilcox wrote:



On Sun, 31 Jul 2005, Geoff Huston wrote:

So - to NANOG at large - if you want your vendor to include 4-Byte AS 
support
in their BGP code anytime soon, in order to avoid some last minute 
panic in a
couple of years hence, then it would appear that you should talk to 
them now
and say clearly that you want 4-Byte AS support in your BGP software 
right

now.


Geoff, excellent idea..

before I forward this email to my suppliers tho, is there a reference 
I can
send.. excuse my ignorance but I'm not familiar with research done on 
4-byte

ASNs, is there a proposed standard implementation?

If I have something definite to request I will immediately send those 
emails,


draft-ietf-idr-as4bytes-10 seems to be the document to point them at.

http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-10.txt


Joe

Re: as numbers

[Gaurab Raj Upadhaya]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Anyone who uses the argument of inter-domain routing that are not  
seen by
any data collectors on the Internet should be pointed at RFC1930  
and told

to renumber their private ASNs.



Just because public route collectors can't see use of an ASN, that  
doesn't mean the ASN isn't in use; just because it can't be seen  
doesn't mean it's private-use: it might still feature on routes  
announced on the Internet, even if the routes don't propagate  
globally.


For a trivial example of this, consider a multilat route server at  
an exchange point. Unless you measure from within (or downstream  
of) a peer of the route server, you'll never see the AS number in  
an AS_PATH attribute. It's fairly clear to me that this is not a  
suitable candidate for private-use numbering, however.




I can see that happening all over the place where external  
connectivity is pre-dominantly over satellite, or where there is a  
monopoly in transit services.  The ASN are used mainly at the local  
IXP, where RFC 1930 and private ASN won't be useful, but at the same  
time external connectivity is default routed to the transit provider.  
Thus the ASN are not seen in any AS_PATH by any data collector,  
doesn't mean that they are not being used.


thanks

   -- gaurab


/+9779851038080
gaurab at lahai dot com

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC7ltOSo7fU26F3X0RAnbuAKC7BtfKZ8lD1g+v2bdcn0EAryCU6QCcDxB2
YiXVItqcDhB5i+mAijEBNzQ=
=LJLZ
-END PGP SIGNATURE-

Re: as numbers

[Stephen J. Wilcox]

On Sun, 31 Jul 2005, Geoff Huston wrote:

> So - to NANOG at large - if you want your vendor to include 4-Byte AS support
> in their BGP code anytime soon, in order to avoid some last minute panic in a
> couple of years hence, then it would appear that you should talk to them now
> and say clearly that you want 4-Byte AS support in your BGP software right
> now.

Geoff, excellent idea..

before I forward this email to my suppliers tho, is there a reference I can
send.. excuse my ignorance but I'm not familiar with research done on 4-byte
ASNs, is there a proposed standard implementation?

If I have something definite to request I will immediately send those emails,

Steve

Re: as numbers

[bmanning]

On Mon, Aug 01, 2005 at 09:17:58AM +0200, Daniel Karrenberg wrote:
> On 31.07 17:20, [EMAIL PROTECTED] wrote:
> > 
> > we did that (move a root) in the CIDR /8 experiment.
> > we could do it for this too :)
> 
> one root name server: yes
> the root name servers: no, definitely not
> 
> Daniel
> 
> PS: Ony as soon as implementations are available of course ! ;-(

we didn't move all of them last time, doing so now would be foolish.
one, yes... 

--bill

Re: as numbers

[Daniel Karrenberg]

On 31.07 17:20, [EMAIL PROTECTED] wrote:
> 
>   we did that (move a root) in the CIDR /8 experiment.
>   we could do it for this too :)

one root name server: yes
the root name servers: no, definitely not

Daniel

PS: Ony as soon as implementations are available of course ! ;-(

Re: as numbers

[bmanning]

On Sun, Jul 31, 2005 at 08:08:37PM +0300, Petri Helenius wrote:
> 
> [EMAIL PROTECTED] wrote:
> 
> 
> 
> >
> > nice... so one or more of the RIRs should ask the IANA
> > for a delegation in the 4byte space and let a few 
> > brave souls run such a trap.  The IETF has a proces 
> > for running such experiments that could be applied here.
> >
> > should I write it up and get the ball rolling?
> >
> > 
> >
> Could the root-servers be moved to the 4 byte space?
> 
> Pete
> 


we did that (move a root) in the CIDR /8 experiment.
we could do it for this too :)

--bill

Re: as numbers

[Bill Woodcock]

> > Given the interest in whether 4 byte AS numbers will function, when 
> > will a test network be put up using a 4 byte AS, and announced so 
> > that everyone can test their readiness?
> > 
> > A server hosted on such a network probably could produce a weekly 
> > report, similar to the CIDR report, that shows the differences 
> > between two byte AS connectivity and 4 byte, and gives a list of the 
> > networks that have issues with 4 byte AS space. At least that way 
> > there'd be some real data to argue about. 

I think PCH, RIS, and Route-Views can handle the collection side of it, 
and I'm sure we can coordinate on the back-end to make a single report.

-Bill

Re: as numbers

[Petri Helenius]

[EMAIL PROTECTED] wrote:





nice... so one or more of the RIRs should ask the IANA
	for a delegation in the 4byte space and let a few 
	brave souls run such a trap.  The IETF has a proces	

for running such experiments that could be applied here.

should I write it up and get the ball rolling?

 


Could the root-servers be moved to the 4 byte space?

Pete

Re: as numbers

[bmanning]

> Given the interest in whether 4 byte AS numbers will function, when 
> will a test network be put up using a 4 byte AS, and announced so 
> that everyone can test their readiness?
> 
> A server hosted on such a network probably could produce a weekly 
> report, similar to the CIDR report, that shows the differences 
> between two byte AS connectivity and 4 byte, and gives a list of the 
> networks that have issues with 4 byte AS space. At least that way 
> there'd be some real data to argue about. 

nice... so one or more of the RIRs should ask the IANA
for a delegation in the 4byte space and let a few 
brave souls run such a trap.  The IETF has a proces 
for running such experiments that could be applied here.

should I write it up and get the ball rolling?

--bill

Re: as numbers

[Daniel Senie]

At 10:51 AM 7/31/2005, Joe Abley wrote:



On 31 Jul 2005, at 01:23, Robert Boyle wrote:

I agree that implementation sooner rather than later is a good 
idea, but all of us already have a 2-Byte AS so although we care in 
theory and believe it is a good idea, we don't _really_ care as 
much as the first guy who gets a 4-Byte AS will.


The first guy who gets a 4-byte AS number is going to be one of our 
customers. If we want to be able to talk BGP with him, we need 
4-byte AS number support in our edge routers.


ISPs who have an interest in continuing to win transit customers 
past 2008/2009 should be interested in getting 4-byte AS number 
support, regardless of how many 2-byte AS numbers they already have. 
ISPs who plan to stop getting new customers don't need to bother :-)


As new /8's of address space are going up, various folks on NANOG 
have asked for test addresses within the block to be made live so 
that testing can be done.


Given the interest in whether 4 byte AS numbers will function, when 
will a test network be put up using a 4 byte AS, and announced so 
that everyone can test their readiness?


A server hosted on such a network probably could produce a weekly 
report, similar to the CIDR report, that shows the differences 
between two byte AS connectivity and 4 byte, and gives a list of the 
networks that have issues with 4 byte AS space. At least that way 
there'd be some real data to argue about. 

Re: as numbers

[Robert Boyle]

At 10:51 AM 7/31/2005, Joe Abley wrote:
I agree that implementation sooner rather than later is a good idea, but 
all of us already have a 2-Byte AS so although we care in theory and 
believe it is a good idea, we don't _really_ care as much as the first 
guy who gets a 4-Byte AS will.


The first guy who gets a 4-byte AS number is going to be one of our 
customers. If we want to be able to talk BGP with him, we need 4-byte AS 
number support in our edge routers.


I know, understand, and agree. He is going to be one of our customers, but 
he isn't us and the new 4-byte AS allocations aren't real yet either. I'm 
just saying that of all the things that we (nanog collectively, not just 
Tellurian) need our router vendors to do, this is on the list, but it isn't 
#1 or maybe even in the top ten. However, I would also rather have it 
BEFORE we need it. Is 2005 too soon for people to _demand_ it? Maybe...


ISPs who have an interest in continuing to win transit customers past 
2008/2009 should be interested in getting 4-byte AS number support, 
regardless of how many 2-byte AS numbers they already have. ISPs who plan 
to stop getting new customers don't need to bother :-)


Of course! I agree with you, but the point I'm trying to make is that I 
don't expect most ISPs to prioritize this feature with their vendors until 
about January 2008. That means we'll have buggy 4-byte AS code until about 
summer 2009. :P


-R


Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin

Re: as numbers

[Joe Abley]

On 31 Jul 2005, at 01:23, Robert Boyle wrote:

I agree that implementation sooner rather than later is a good idea, 
but all of us already have a 2-Byte AS so although we care in theory 
and believe it is a good idea, we don't _really_ care as much as the 
first guy who gets a 4-Byte AS will.


The first guy who gets a 4-byte AS number is going to be one of our 
customers. If we want to be able to talk BGP with him, we need 4-byte 
AS number support in our edge routers.


ISPs who have an interest in continuing to win transit customers past 
2008/2009 should be interested in getting 4-byte AS number support, 
regardless of how many 2-byte AS numbers they already have. ISPs who 
plan to stop getting new customers don't need to bother :-)



Joe

Re: as numbers

[Robert Boyle]

At 01:12 AM 7/31/2005, you wrote:
This kind of response does have a certain market-based logic to it, I must 
admit, but its highly risky. I don't think its all that wise for this to be 
delayed indefinitely until the point at which its turning from an orderly 
transition into a last second panic, and I don't think that many customers 
will place this high on their vendor support priority list until they are 
actually allocated a 4-byte AS number because the 2-byte pool has been 
exhausted. .


So - to NANOG at large - if you want your vendor to include 4-Byte AS 
support in their BGP code anytime soon, in order to avoid some last minute 
panic in a couple of years hence, then it would appear that you should 
talk to them now and say clearly that you want 4-Byte AS support in your 
BGP software right now.


I agree that implementation sooner rather than later is a good idea, but 
all of us already have a 2-Byte AS so although we care in theory and 
believe it is a good idea, we don't _really_ care as much as the first guy 
who gets a 4-Byte AS will. Eventually one of our BGP speaking transit 
customers will be assigned these AS numbers and other newer providers will 
too, but unless someone plans to chop up their network or split into two 
companies, I don't see that there will be much clamoring for this - yet. 
When we can't provide connectivity to a potential customer because we can't 
accept or wrap up their 4B AS, then there will be demand. Just some food 
for thought...


-R


Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin

Re: as numbers

[Geoff Huston]

At 05:13 PM 30/07/2005, Daniel Karrenberg wrote:

Henk hits the nail on the head. And reclamation is not straightforward:

The RIPE NCC has hit strong resistance to reclamation, most often with
the argument that the ASes are used in inter-domain routing on the
Internet but our BGP data collectors just do not see the paths
concerned.  It takes considerable effort to do reclamation properly
whithout putting the future user of any reclaimed number space at risk!

Also: I think we should all be very concerned about this. As with all such
projections, Geoff's are valid only for an unchanged consumtion pattern.
If I was running a network I would start to ask my vendors serious questions
and start to prepare deployment scenarios.



The trends --within the current figures-- appear to indicate that the 
first >0:x  AS number will be issued no later than 2010, and more 
likely to be sometime in 2009. The write-up referenced by Randy at the 
start of the thread shows the underlying basis of this predictive exercise, 
and illustrates the nature of the non-linear drivers behind AS number 
consumption.

(http://www.potaroo.net/ispcol/2005-08/as.html)

When reviewing the 4-byte AS draft on this I sensed that the authors were 
skeptical that all AS's would be running an upgraded BGP version that had 
the 4-byte capabilities at any particular time, and for that reason devised 
the mechanisms for the upgraded BGP speakers on a 4-byte / 2-byte boundary 
to package up the 4-byte AS path information in a special attribute that is 
opaque to the 2-byte BGP speaker and unwrap it at corresponding 2-byte -> 
4-byte transition. This approach appears to be robust to me, on the basis 
that we can take the additional memory hit  of having some additional 12Mb 
or so in each ADJ-RIB within the 2-byte world, and then do not have to pull 
the entire inter-domain routing world into a coordinated software upgrade.


I have looked at reclamation - the basic observation is that old AS's do 
gradually disappear off the network, and the longer the time period since 
the original allocation the more likely it is that the AS has disappeared 
(the relationship appears to be close to directly proportional). But 
reclamation will buy you some further time, but not an indefinite future. 
And here, unlike the v4 / v6 transition, there is no _need_ for the 
existing 2-byte AS to change any time soone - they can still exist in a 
mixed 2 / 4 byte AS world (the only change that may have some minor impact 
is the issue of embedding AS numbers in BGP communities, in which case 
support for extended communities is necessary.


So it appears to me that the 'piecemeal' transition will work well, and the 
big milestone right now is to convince BGP providers, such as Open BGP, 
Zebra, Cisco, Juniper, etc  to produce 4-byte versions of their BGP 
implementations right _now_ that supports all the functionality as 
described in the 4-byte AS draft.


Last time I raised this matter with a large vendor I received the response 
(paraphrased) "Our customers have not said they want this, so we will not 
be doing anything until our customers say that they need this added to our 
BGP implementation."


This kind of response does have a certain market-based logic to it, I must 
admit, but its highly risky. I don't think its all that wise for this to be 
delayed indefinitely until the point at which its turning from an orderly 
transition into a last second panic, and I don't think that many customers 
will place this high on their vendor support priority list until they are 
actually allocated a 4-byte AS number because the 2-byte pool has been 
exhausted. .


So - to NANOG at large - if you want your vendor to include 4-Byte AS 
support in their BGP code anytime soon, in order to avoid some last minute 
panic in a couple of years hence, then it would appear that you should talk 
to them now and say clearly that you want 4-Byte AS support in your BGP 
software right now.


regards,

Geoff

Re: as numbers

[Joe Abley]

On 30 Jul 2005, at 15:03, Hank Nussbacher wrote:


On Sat, 30 Jul 2005, Daniel Karrenberg wrote:


The RIPE NCC has hit strong resistance to reclamation, most often with
the argument that the ASes are used in inter-domain routing on the
Internet but our BGP data collectors just do not see the paths
concerned.  It takes considerable effort to do reclamation properly
whithout putting the future user of any reclaimed number space at 
risk!


Anyone who uses the argument of inter-domain routing that are not seen 
by
any data collectors on the Internet should be pointed at RFC1930 and 
told

to renumber their private ASNs.


Just because public route collectors can't see use of an ASN, that 
doesn't mean the ASN isn't in use; just because it can't be seen 
doesn't mean it's private-use: it might still feature on routes 
announced on the Internet, even if the routes don't propagate globally.


For a trivial example of this, consider a multilat route server at an 
exchange point. Unless you measure from within (or downstream of) a 
peer of the route server, you'll never see the AS number in an AS_PATH 
attribute. It's fairly clear to me that this is not a suitable 
candidate for private-use numbering, however.



Joe

Re: as numbers

[Hank Nussbacher]

On Sat, 30 Jul 2005, Daniel Karrenberg wrote:

> The RIPE NCC has hit strong resistance to reclamation, most often with
> the argument that the ASes are used in inter-domain routing on the
> Internet but our BGP data collectors just do not see the paths
> concerned.  It takes considerable effort to do reclamation properly
> whithout putting the future user of any reclaimed number space at risk!

Anyone who uses the argument of inter-domain routing that are not seen by
any data collectors on the Internet should be pointed at RFC1930 and told
to renumber their private ASNs.

-Hank

Re: as numbers

[Daniel Karrenberg]

On 29.07 09:59, Henk Uijterwaal wrote:
> 
> I'd think that 30 days is too low.  What we see (*) is that after 30 days,
> only half of the assigned ASN have appeared on the Internet.  Some 75%
> of the assigned ASN appear on the net in the first 6 months after
> assignment, 80-85% after a year.  Anything not seen after a year (15-20%),
> is unlikely to ever appear, these can be recovered (at least in theory).
> 
> While this looks like a lot, it does not really solve any problem.  Geoff's
> numbers show that the pool will expire in 5 years.  Our estimate is a
> little bit longer, but not that much.  2010-2005 is 5 years, if the trend
> that 20% never appears continues and all these ASN are revoked, this simply
> means that the pool will  expire in 6 years.  2010 or 2011 hardly makes a
> difference.

Henk hits the nail on the head. And reclamation is not straightforward:

The RIPE NCC has hit strong resistance to reclamation, most often with
the argument that the ASes are used in inter-domain routing on the
Internet but our BGP data collectors just do not see the paths
concerned.  It takes considerable effort to do reclamation properly
whithout putting the future user of any reclaimed number space at risk! 

Also: I think we should all be very concerned about this. As with all such 
projections, Geoff's are valid only for an unchanged consumtion pattern.  
If I was running a network I would start to ask my vendors serious questions 
and start to prepare deployment scenarios.

Daniel

Re: as numbers

[Randy Bush]

> The article states it's not fixed.

that seems to agree with at least one of my routers

rtr42#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
rtr42(config)#router bgp 0:3130
^
% Invalid input detected at '^' marker.

my point was that the roll-out geoff suggests may be more
conservative than needed.  depends on how long the ivtf
takes to specify and how long the vendors take to implement.

randy

Re: as numbers

[Mikael Abrahamsson]

On Fri, 29 Jul 2005, Randy Bush wrote:


you may want to read the referenced article

  


The article states it's not fixed. I guess what I was told back then was 
false, considering 
 states:


"While there is no immediate danger of exhausting the 16-bit AS number 
space, several factors, principally the need of enterprises to run BGP to 
multihome, is reason for concern that more space will be needed in the 
moderate term. As of mid-2005, the IETF has several drafts underway that 
define mechanisms for the use of an upwardly compatible four-octet, or 
32-bit, AS number space. This space will not replace the existing 16-bit 
space."


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: as numbers

[Randy Bush]

>> While this looks like a lot, it does not really solve any problem.  Geoff's
>> numbers show that the pool will expire in 5 years.  Our estimate is a
> When discussed a few years back, I was told that this was already solved 
> by 32bit AS numbers (ASx:x).

you may want to read the referenced article

   

randy

Re: as numbers

[Fredy Kuenzler]

Henk Uijterwaal wrote:

While this looks like a lot, it does not really solve any problem.
Geoff's numbers show that the pool will expire in 5 years.  Our
estimate is a little bit longer, but not that much.  2010-2005 is 5
years, if the trend that 20% never appears continues and all these
ASN are revoked, this simply means that the pool will  expire in 6
years.  2010 or 2011 hardly makes a difference.


Also consider that there will be likely a clearance sale rush, so I
expect, unless there is a practical solution, the pool will expire even
earlier, 2008 or 2009.

Fredy

Re: as numbers

[Mikael Abrahamsson]

On Fri, 29 Jul 2005, Henk Uijterwaal wrote:


While this looks like a lot, it does not really solve any problem.  Geoff's
numbers show that the pool will expire in 5 years.  Our estimate is a


When discussed a few years back, I was told that this was already solved 
by 32bit AS numbers (ASx:x).


Has anything changed?

--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: as numbers

[Henk Uijterwaal]

Hank,

At 09:13 29/07/2005, Hank Nussbacher wrote:


"Of the 32,557 assigned AS numbers, some 19,859 are advertised, while
12,698 have been allocated in the past, but are not currently advertised
in the BGP routing table."

I would have liked to see how well the RIRs are at recovering unused
ASNs, if at all.  For example ARIN has a 30 day policy:
http://www.arin.net/registration/templates/asn-request.txt

Do the RIRs *ever* revoke an ASN after the customer does not follow the
RIR stated rules?  Would love to see numbers on that issue.  No wonder the
ASN pool will expire in 2010.


I'd think that 30 days is too low.  What we see (*) is that after 30 days,
only half of the assigned ASN have appeared on the Internet.  Some 75%
of the assigned ASN appear on the net in the first 6 months after
assignment, 80-85% after a year.  Anything not seen after a year (15-20%),
is unlikely to ever appear, these can be recovered (at least in theory).

While this looks like a lot, it does not really solve any problem.  Geoff's
numbers show that the pool will expire in 5 years.  Our estimate is a
little bit longer, but not that much.  2010-2005 is 5 years, if the trend
that 20% never appears continues and all these ASN are revoked, this simply
means that the pool will  expire in 6 years.  2010 or 2011 hardly makes a
difference.

Henk

* Some of our research was presented by Rene Wilhelm @ RIPE50 last May,
  http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-mon-asmia.pdf, 
we have some additional results.  We are working on a write-up

  of all our results, stay tuned.


--
Henk Uijterwaal   Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre  http://www.amsterdamned.org/~henk
P.O.Box 10096  Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam  1016 AB Amsterdam  Fax: +31.20.5354445
The NetherlandsThe NetherlandsMobile: +31.6.55861746
--

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad. (Tom Verlaine) 

Re: as numbers

[Hank Nussbacher]

On Fri, 29 Jul 2005, Randy Bush wrote:

Geoff,

"Of the 32,557 assigned AS numbers, some 19,859 are advertised, while
12,698 have been allocated in the past, but are not currently advertised
in the BGP routing table."

I would have liked to see how well the RIRs are at recovering unused
ASNs, if at all.  For example ARIN has a 30 day policy:
http://www.arin.net/registration/templates/asn-request.txt

Do the RIRs *ever* revoke an ASN after the customer does not follow the
RIR stated rules?  Would love to see numbers on that issue.  No wonder the
ASN pool will expire in 2010.

-Hank

>
> > geoff has a quite good article on antonymous systems, usage, ... at
> > .
>
> geoff,
>
> why not assume
>   o all speakers will not transition at the same time, but
>   o before the first > 0: is issued/used that all will
> transition?
>
> i would think this is operationally viable.
>
> randy

Re: as numbers

[Randy Bush]

> geoff has a quite good article on antonymous systems, usage, ... at
> .

geoff,

why not assume
  o all speakers will not transition at the same time, but
  o before the first > 0: is issued/used that all will
transition?

i would think this is operationally viable.

randy