Re: If I announce 192.0.2.0/24, do I need a discard route? (Looking for a reference…)

[Warren Kumari]

On Wed, Jan 31, 2024 at 5:56 PM, Owen DeLong  wrote:

> On Jan 31, 2024, at 13:46, Warren Kumari  wrote:
>
>
>
>
>
> On Wed, Jan 31, 2024 at 3:56 PM, William Herrin  wrote:
>
>> On Wed, Jan 31, 2024 at 12:30 PM Warren Kumari 
>> wrote:
>>
>> So, let's say I'm announcing some address space (e.g 192.0.2.0/24), but
>> I'm only using part of it internally (e.g 192.0.2.0/25). I've always
>> understood that it's best practice[0] to have a discard route (eg static to
>> null0/discard or similar[1]) for what I'm announcing.
>>
>> Hi Warren,
>>
>> Your router won't announce 192.0.2.0/24 unless it knows a route to 192.0.
>> 2.0/24 or has been configured to aggregate any internal routes inside
>> 192.0.2.0/24 to 192.0.2.0/24.
>>
>
> It that always true? I'd started off thinking that, but a friend of mine
> (yes, the same one that started this  argument) convinced me that
> some forms of BGP summarization/aggregation don't always generate a "local"
> route…
>
>
> It’s not ALWAYS true. For example, aggregate-address commands and
> equivalent on many platforms will cause the route to be announced if any
> component prefixes are present in the RIB on some platforms.
>
> There are also some cases where “auto-summary” (does anyone actually use
> this? EVER?) will have a similar effect.
>
> There are also some implementations where disabling synchronization or in
> many cases where synchronization has simply been deprecated by the
> implementor where any bap “network” statement (or equivalent) will result
> in announcement regardless of what’s in the RIB.
>
> I'd also thought that I'd seen this when redistributing an IGP into BGP,
> and using that as a contributor to 'aggregate-address' on Cisco devices.
> This is from a long time ago, and really hazy now, but I'd thought that any
> contributor would cause that the aggregate-address route to be announced,
> and a local hold down not to be created.  It's possible that a: I'm just
> wrong b: this is not longer true, c: both of the above.
>
>
> Redistributing an IGP into BGP is almost always a bad idea. However, that
> aside, yes, as mentioned above, exactly what you are saying here is true
> with or without the redistribution on most platforms IIRC.
>
> a: you are not wrong
> b: it’s still true on many platforms at least (though may be
> implementation dependent)
> c: no, but it’s certainly not best practice to behave in this way or
> depend on either of these behaviors for the other original reason you
> stated among other reasons.
>
> With BGP, you really want to have a deterministic clean definition of what
> your router will do. As a general rule, if your peer is reachable, you
> usually want to advertise your originated routes to them and make damn sure
> your router can reach those some how no matter what.
>


Yah, agreed…. This seems "obvious", but is there actually anything that
states this? I'm not really sure where I think that I'd find something
authoritative *to* state something.

Even though we claim to be network **engineers**, there isn't really very
much documentation of correct behavior — there are things like the MANRS
docs, and the short-lived BCOPS series, but much of the rest of the
understanding of what is appropriate / best practice seems to be
undocumented and passed on through cultural diffusion, pointing at some
NANOG post from 1998, or vague handwaving  towards the cymu secure IOS
template….

I was initially excited by Tom's pointing at RFC4271, Sec 9.1.3, which
states:
"A route SHALL NOT be installed in the Adj-Rib-Out unless the destination,
and NEXT_HOP described by this route, may be forwarded appropriately
by the Routing
Table."

This sounded perfect, and I could beat my friend around the head with
it… but reading further reveals:
"Route aggregation and information reduction techniques (see
Section 9.2.2.1) may optionally be applied.

 Any local policy that results in routes being added to an Adj-RIB-Out
without also being added to the local BGP speaker's forwarding table is
outside the scope of this document."

W

>
> There are also some more inventive ways of getting routes into BGP, like
> using ExaBGP as an example.
>
>
> Sure, but using ExaBGP really amounts to originating the prefix from
> another router. This discussion was (at least theoretically) about local
> origination on the router in question.
>
> Owen
>
>
> W
>
>
>
> 192.0.2.0/25 doesn't count; it needs to know a route to 192.0.2.0/24.
>> Sending 192.0.2.0/24 to discard guarantees that the router has a route
>> to 192.0.2.0/24.
>>
>> Historically, folks would put 192.0.2.0/24 on the ethernet port. Then,
>> when carrier was lost on the ethernet port for a moment, the router would
>> no longer have a route to 192.0.2.0/24, so it'd withdraw the
>> announcement for 192.0.2.0/24. This is a bad idea for obvious reasons,
>> so best practice was to put a low priority route to discard as a fall-back
>> if the ethernet port briefly lost carrier.
>>
>> Regards,
>> Bill Herrin
>>
>> --
>> 

[NANOG-announce] NANOG 90 Keynote: Abstract Ponderings - A Ten-Year Retrospective with Google's Rob Shakir + More

[Nanog News]

*NANOG 90 Keynote: Abstract Ponderings**A Ten-Year Retrospective with
Google's Rob Shakir*

Rob Shakir, a senior staff software engineer for Google, will be a keynote
speaker at NANOG's upcoming 90th community-wide conference.

"We've got various internal company systems that use Open Config. It's now
the time to step back and ask, 'Are we doing this right, and what did we do
wrong?'" he said.

*READ NOW
*

*Check out the NANOG 90 Social Lineup!  *

NANOG Socials are your opportunity to get to know your peers in the
industry + foster important relationships in a relaxed, casual, and fun
environment.

*VIEW NOW  *

*NANOG 90 Talks Not to Miss *

*BGP in 2023* w/ Geoff Huston
*Panel: Network Automation Showdown: Go vs. Python* - see agenda
*Greenlight - Community Assets Evolving to Meet Customer's Needs* w/
Linwood Tyndall
*Is there a Genuine Need for ML/AI in the Internet and Networking?* w/ JP
Vasseur

*SEE FULL AGENDA  *
*Register Now for N90 Hackathon! *
*Networking Opportunities, Hands-On Learning, + Fun! *

Theme: New Year - New Hack Format!

The NANOG 90 Hackathon will focus on "Problem Solving/Troubleshooting"
competitions. During this Hackathon, teams will collaborate to solve the
posed problems.

Scoring will be based on network reachability and how fast participants
solve the problems. Prizes will be provided to the top finishers!

*REGISTER NOW * 
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

NANOG 90 Keynote: Abstract Ponderings - A Ten-Year Retrospective with Google's Rob Shakir + More

[Nanog News]

*NANOG 90 Keynote: Abstract Ponderings**A Ten-Year Retrospective with
Google's Rob Shakir*

Rob Shakir, a senior staff software engineer for Google, will be a keynote
speaker at NANOG's upcoming 90th community-wide conference.

"We've got various internal company systems that use Open Config. It's now
the time to step back and ask, 'Are we doing this right, and what did we do
wrong?'" he said.

*READ NOW
*

*Check out the NANOG 90 Social Lineup!  *

NANOG Socials are your opportunity to get to know your peers in the
industry + foster important relationships in a relaxed, casual, and fun
environment.

*VIEW NOW  *

*NANOG 90 Talks Not to Miss *

*BGP in 2023* w/ Geoff Huston
*Panel: Network Automation Showdown: Go vs. Python* - see agenda
*Greenlight - Community Assets Evolving to Meet Customer's Needs* w/
Linwood Tyndall
*Is there a Genuine Need for ML/AI in the Internet and Networking?* w/ JP
Vasseur

*SEE FULL AGENDA  *
*Register Now for N90 Hackathon! *
*Networking Opportunities, Hands-On Learning, + Fun! *

Theme: New Year - New Hack Format!

The NANOG 90 Hackathon will focus on "Problem Solving/Troubleshooting"
competitions. During this Hackathon, teams will collaborate to solve the
posed problems.

Scoring will be based on network reachability and how fast participants
solve the problems. Prizes will be provided to the top finishers!

*REGISTER NOW * 

Re: NANOG Digest, Vol 193, Issue 1

[Jakob Heitz (jheitz) via NANOG]

Wow!
The reason it’s called generative AI is because it totally made that up.

Kind Regards,
Jakob


Date: Wed, 31 Jan 2024 18:27:24 +
From: "Compton, Rich" 
To: Mohammad Khalil , NANOG list 
Subject: Re: SOVC - BGp RPKI
Message-ID:



Content-Type: text/plain; charset="utf-8"

ChatGPT says:
SOVC in the context of RPKI (Resource Public Key Infrastructure) on a Cisco 
router stands for "Stale Origin Validation Cache". RPKI is a security framework 
designed to secure the Internet's routing infrastructure, primarily through 
route origin validation. It ensures that the Internet number resources (like IP 
addresses and AS numbers) are used by the legitimate owners or authorized AS 
(Autonomous System).
In RPKI, Route Origin Authorizations (ROAs) are used to define which AS is 
authorized to announce a specific IP address block. Network devices, like Cisco 
routers, use these ROAs to validate the authenticity of BGP (Border Gateway 
Protocol) route announcements.
The term "stale" in SOVC refers to a situation where the router's 
RPKI-to-Router protocol client has lost its connection to the RPKI server, or 
when the RPKI cache data is outdated and not refreshed for some reason. This 
can happen due to network issues, configuration errors, or problems with the 
RPKI server itself. When the RPKI cache is stale, the router cannot reliably 
validate BGP route announcements against the latest ROA data, potentially 
affecting routing decisions.
In a network security context, maintaining an up-to-date RPKI cache is crucial 
for ensuring that the network only accepts legitimate routing announcements, 
thereby reducing the risk of routing hijacks or misconfigurations. As a network 
security engineer, managing and monitoring the RPKI status on routers is an 
important aspect of ensuring network security and integrity.

Re: SOVC - BGp RPKI

[Jakob Heitz (jheitz) via NANOG]

In bgp_sovc.h, at the top, it says:
BGP Secure Origin Validation Code
Further down in the file, it says:
BGP Secured Origin Validate Cache – SOVC

Basically, the router downloads the VRPs from the RPKI server, using RFC 6810.
Then it uses the downloaded VRPs to validate received routes using RFC 6811.
SOVC refers to the code that does that.

Kind Regards,
Jakob


Date: Wed, 31 Jan 2024 16:16:15 +0300
From: Mohammad Khalil 
To: NANOG list 

Greetings
Am have tried to find out what is the abbreviation for SOVC with no luck.

#sh bgp ipv4 unicast rpki servers
BGP SOVC neighbor is X.X.X.47/323 connected to port 323

Anyone have encountered this?

Thanks!

Re: route: 0.0.0.0/32 in LEVEL3 IRR

[Tom Beecher]

Yes, absolutely. That's part of the technical risk that you take if you
decide to do such things.

If it's a "good" choice or not is entirely situational. Some organizations
are fine with kicking that tech debt down the road, others like to double
down and create a house of cards.

On Thu, Feb 1, 2024 at 2:21 AM Frank Habicht  wrote:

> On 01/02/2024 01:45, Tom Beecher wrote:
> > Seems a bit dramatic. Companies all over the world have been using other
> > people's public IPs internally for decades. I worked at a place 20 odd
> > years ago that had an odd numbering scheme internally, and it was
> > someone else's public space. When I asked why, the guy who built it said
> > "Well I just liked the pattern."
> >
> > If you're not announcing someone else's space into the DFZ, or
> > otherwise trying to do anything shady, the three letter agencies aren't
> > likely to come knocking. Doesn't mean anyone SHOULD be doing it, but
> still.
>
> Well...
>
> If you're using 20.20.20.0/24 which is not "yours" (as I've seen
> happen), then certainly your customers can't get to the real 20.20.20.x
> And even if that's not announced and used /today/ - this can change
> quickly...
>
> Frank
>

Re: SOVC - BGp RPKI

[Mohammad Khalil]

Thanks all for the kind reply and feedback. I guess Sofia listed the needed
: )

On Thu, 1 Feb 2024 at 13:25, Sofia Silva Berenguer  wrote:

> How polite of it to apologize!!
>
>
>
> I asked Bing’s Copilot and it says SOVC stands for “Signed Object
> Validation Cache” but I wasn’t able to get a source for that either ☹
>
>
>
> Oh these AI times…
>
>
>
> Warm regards,
>
> Sofía
>
> --
>
> *I am sending this email at a time that suits me and the time zone I work
> in. Please feel free to read, and act on or respond, at a time that suits
> you.*
>
>
>
> 
>
> Sofía Silva Berenguer
>
> RPKI Program Manager, NRO / Process and Productivity Engineer, APNIC
>
> e: so...@apnic.net
>
> 
>
>
>
>
>
> *From: *NANOG  on behalf of
> Compton, Rich via NANOG 
> *Date: *Thursday, 1 February 2024 at 9:10 am
> *To: *Justin H. , NANOG list 
> *Subject: *Re: SOVC - BGp RPKI
>
> I think it hallucinated.
>
> When asked to site its sources:
>
>
>
> “I apologize for the confusion, but my response about "SOVC" in the
> context of RPKI on Cisco routers was based on general knowledge of RPKI and
> networking principles, not from a specific source. The explanation combined
> standard practices and concepts in network security and routing, especially
> as they relate to RPKI and BGP.
>
> Since the acronym "SOVC" is not a standard or widely recognized term in
> the context of RPKI, it's possible that it might be specific to certain
> environments or proprietary to certain Cisco router models or software
> versions. For the most accurate and detailed information, it's always best
> to consult the official Cisco documentation or support resources,
> especially for terms that might be specific to their products.”
>
>
>
> *From: *NANOG  on
> behalf of Justin H. 
> *Date: *Wednesday, January 31, 2024 at 3:06 PM
> *To: *NANOG list 
> *Subject: *Re: SOVC - BGp RPKI
>
> I'd be curious to know why it thinks that the S is "Stale".  I don't
> suppose it cites its sources?
>
> Compton, Rich via NANOG wrote:
> >
> > ChatGPT says:
> >
> > SOVC in the context of RPKI (Resource Public Key Infrastructure) on a
> > Cisco router stands for "Stale Origin Validation Cache". RPKI is a
> > security framework designed to secure the Internet's routing
> > infrastructure, primarily through route origin validation. It ensures
> > that the Internet number resources (like IP addresses and AS numbers)
> > are used by the legitimate owners or authorized AS (Autonomous System).
> >
> > In RPKI, Route Origin Authorizations (ROAs) are used to define which
> > AS is authorized to announce a specific IP address block. Network
> > devices, like Cisco routers, use these ROAs to validate the
> > authenticity of BGP (Border Gateway Protocol) route announcements.
> >
> > The term "stale" in SOVC refers to a situation where the router's
> > RPKI-to-Router protocol client has lost its connection to the RPKI
> > server, or when the RPKI cache data is outdated and not refreshed for
> > some reason. This can happen due to network issues, configuration
> > errors, or problems with the RPKI server itself. When the RPKI cache
> > is stale, the router cannot reliably validate BGP route announcements
> > against the latest ROA data, potentially affecting routing decisions.
> >
> > In a network security context, maintaining an up-to-date RPKI cache is
> > crucial for ensuring that the network only accepts legitimate routing
> > announcements, thereby reducing the risk of routing hijacks or
> > misconfigurations. As a network security engineer, managing and
> > monitoring the RPKI status on routers is an important aspect of
> > ensuring network security and integrity.
> >
> > I see it mentioned in this doc:
> >
> >
> https://urldefense.com/v3/__https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-origin-as.pdf__;!!CQl3mcHX2A!EB5iIYDDpnRMSM7Gjvy11sMoEsjEDlXtTpfipi4l735bx04IY-dD73vWGCbiDZvoRR6kTse35whqa8dH1cN_Ya9j$
> 
> >
> > *From: *NANOG  on
> > behalf of Mohammad Khalil 
> > *Date: *Wednesday, January 31, 2024 at 10:35 AM
> > *To: *NANOG list 
> > *Subject: *SOVC - BGp RPKI
> >
> > Greetings Am have tried to find out what is the abbreviation for SOVC
> > with no luck. #sh bgp ipv4 unicast rpki servers  BGP SOVC 

Re: SOVC - BGp RPKI

[Dominik Dobrowolski (dodobrow) via NANOG]

I can confirm that the official abbreviation is: Secured Origin Validate Cache

Kind Regards,
Dominik Dobrowolski

[Cisco White/Blue Both Lines]

Dominik Dobrowolski

Technical Consulting Engineer

Global CX Centers – Enterprise Switching .:|:.:|:.
Customer Experience

dodob...@cisco.com

Tel: +48 12 321 29 03


Cisco Systems Poland Sp. z o. o.

Aleja Powstancow Wielkopolskich 13C

Enterprise Park

Krakow

Krakow

30-707

Poland

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

Update 
Profile
 - Privacy

Please click 
here
 for Company Registration




From: NANOG on behalf of Sofia Silva Berenguer
Sent: Thursday, February 1, 2024 12:15 AM
To: Compton, Rich; Justin H.; NANOG list
Subject: Re: SOVC - BGp RPKI


How polite of it to apologize!!



I asked Bing’s Copilot and it says SOVC stands for “Signed Object Validation 
Cache” but I wasn’t able to get a source for that either ☹



Oh these AI times…



Warm regards,

Sofía

--

I am sending this email at a time that suits me and the time zone I work in. 
Please feel free to read, and act on or respond, at a time that suits you.





Sofía Silva Berenguer

RPKI Program Manager, NRO / Process and Productivity Engineer, APNIC

e: so...@apnic.net







From: NANOG  on behalf of Compton, 
Rich via NANOG 
Date: Thursday, 1 February 2024 at 9:10 am
To: Justin H. , NANOG list 
Subject: Re: SOVC - BGp RPKI

I think it hallucinated.

When asked to site its sources:



“I apologize for the confusion, but my response about "SOVC" in the context of 
RPKI on Cisco routers was based on general knowledge of RPKI and networking 
principles, not from a specific source. The explanation combined standard 
practices and concepts in network security and routing, especially as they 
relate to RPKI and BGP.

Since the acronym "SOVC" is not a standard or widely recognized term in the 
context of RPKI, it's possible that it might be specific to certain 
environments or proprietary to certain Cisco router models or software 
versions. For the most accurate and detailed information, it's always best to 
consult the official Cisco documentation or support resources, especially for 
terms that might be specific to their products.”



From: NANOG  on behalf of 
Justin H. 
Date: Wednesday, January 31, 2024 at 3:06 PM
To: NANOG list 
Subject: Re: SOVC - BGp RPKI

I'd be curious to know why it thinks that the S is "Stale".  I don't
suppose it cites its sources?

Compton, Rich via NANOG wrote:
>
> ChatGPT says:
>
> SOVC in the context of RPKI (Resource Public Key Infrastructure) on a
> Cisco router stands for "Stale Origin Validation Cache". RPKI is a
> security framework designed to secure the Internet's routing
> infrastructure, primarily through route origin validation. It ensures
> that the Internet number resources (like IP addresses and AS numbers)
> are used by the legitimate owners or authorized AS (Autonomous System).
>
> In RPKI, Route Origin Authorizations (ROAs) are used to define which
> AS is authorized to announce a specific IP address block. Network
> devices, like Cisco routers, use these ROAs to validate the
> authenticity of BGP (Border Gateway Protocol) route announcements.
>
> The term "stale" in SOVC refers to a situation where the router's
> RPKI-to-Router protocol client has lost its connection to the RPKI
> server, or when the RPKI cache data is outdated and not refreshed for
> some reason. This can happen due to network issues, configuration
> errors, or problems with the RPKI server itself. When the RPKI cache
> is stale, the router cannot reliably validate BGP route announcements
> against the latest ROA data, potentially affecting routing decisions.
>
> In a network security context, maintaining an up-to-date RPKI cache is
> crucial for ensuring that the network only accepts legitimate routing
> announcements, thereby reducing the risk of routing hijacks or
> misconfigurations. As a network security engineer, managing and
> monitoring the RPKI status on routers is an important aspect of
> ensuring network security and integrity.
>
> I see it mentioned in this doc:
>
> 

Re: route: 0.0.0.0/32 in LEVEL3 IRR

[Andrian Visnevschi via NANOG]

It's unfortunate, but quite common. I've seen similar occurrences in
several companies I worked for previously. For instance, one of my former
employers utilized public IP addresses belonging to others for IPMI server
access, even though it was solely for management purposes and not
communicated to any peers internally. Consequently, none of the customers
could access these public IPs. The reason for this? When the company
initially acquired these IPs, they were part of a leased range. Upon
termination of the agreement, instead of changing all the IPs, they opted
to continue using them due to the perceived hassle. Similarly, another
service provider used IPs from its leased range for DNS servers. When the
agreement ended and IPs were reallocated, they persisted with the old IPs
because updating DNS server settings on customer CPEs lacked automation and
thought it was too much trouble.

Unfortunately, such examples are not uncommon, and certainly don't
represent best practices



*Andrian Visnevschi*




On Thu, Feb 1, 2024 at 10:58 AM Owen DeLong via NANOG 
wrote:

>
>
> > On Jan 31, 2024, at 23:19, Frank Habicht  wrote:
> >
> > On 01/02/2024 01:45, Tom Beecher wrote:
> >> Seems a bit dramatic. Companies all over the world have been using
> other people's public IPs internally for decades. I worked at a place 20
> odd years ago that had an odd numbering scheme internally, and it was
> someone else's public space. When I asked why, the guy who built it said
> "Well I just liked the pattern."
> >> If you're not announcing someone else's space into the DFZ, or
> otherwise trying to do anything shady, the three letter agencies aren't
> likely to come knocking. Doesn't mean anyone SHOULD be doing it, but still.
> >
> > Well...
> >
> > If you're using 20.20.20.0/24 which is not "yours" (as I've seen
> happen), then certainly your customers can't get to the real 20.20.20.x
> > And even if that's not announced and used /today/ - this can change
> quickly...
> >
> > Frank
>
> You are repeating exactly the argument I made at the time.
>
> Owen
>
>

Re: route: 0.0.0.0/32 in LEVEL3 IRR

[Mark Andrews]

If you are using IPv4 address that belong to someone else internally you really 
are in a prime position to use IPv6 only internally and use one of the IPv4AAS 
mechanisms to reach the IPv4 internet.  After a quarter of a century all your 
equipment should be IPv6 capable. 

-- 
Mark Andrews

> On 1 Feb 2024, at 19:57, Owen DeLong via NANOG  wrote:
> 
> 
> 
>> On Jan 31, 2024, at 23:19, Frank Habicht  wrote:
>> 
>>> On 01/02/2024 01:45, Tom Beecher wrote:
>>> Seems a bit dramatic. Companies all over the world have been using other 
>>> people's public IPs internally for decades. I worked at a place 20 odd 
>>> years ago that had an odd numbering scheme internally, and it was someone 
>>> else's public space. When I asked why, the guy who built it said "Well I 
>>> just liked the pattern."
>>> If you're not announcing someone else's space into the DFZ, or otherwise 
>>> trying to do anything shady, the three letter agencies aren't likely to 
>>> come knocking. Doesn't mean anyone SHOULD be doing it, but still.
>> 
>> Well...
>> 
>> If you're using 20.20.20.0/24 which is not "yours" (as I've seen happen), 
>> then certainly your customers can't get to the real 20.20.20.x
>> And even if that's not announced and used /today/ - this can change 
>> quickly...
>> 
>> Frank
> 
> You are repeating exactly the argument I made at the time.
> 
> Owen
> 

Re: route: 0.0.0.0/32 in LEVEL3 IRR

[Owen DeLong via NANOG]

> On Jan 31, 2024, at 23:19, Frank Habicht  wrote:
> 
> On 01/02/2024 01:45, Tom Beecher wrote:
>> Seems a bit dramatic. Companies all over the world have been using other 
>> people's public IPs internally for decades. I worked at a place 20 odd years 
>> ago that had an odd numbering scheme internally, and it was someone else's 
>> public space. When I asked why, the guy who built it said "Well I just liked 
>> the pattern."
>> If you're not announcing someone else's space into the DFZ, or otherwise 
>> trying to do anything shady, the three letter agencies aren't likely to come 
>> knocking. Doesn't mean anyone SHOULD be doing it, but still.
> 
> Well...
> 
> If you're using 20.20.20.0/24 which is not "yours" (as I've seen happen), 
> then certainly your customers can't get to the real 20.20.20.x
> And even if that's not announced and used /today/ - this can change quickly...
> 
> Frank

You are repeating exactly the argument I made at the time.

Owen