Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-20 Thread Tony Przygienda
ate BGP next hops or other overlay > service routes the disaggregation piece does not apply. > > Cheers, > R. > > > > > > On Fri, Nov 20, 2020 at 9:09 PM Tony Przygienda > wrote: > >> >> >> On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang >> wrote:

Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-20 Thread Tony Przygienda
On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang wrote: > Hi, Tony: > > Aijun Wang > China Telecom > > On Nov 20, 2020, at 17:45, Tony Przygienda wrote: > >  > Yes, acknowledging the idea of negative disaggregation is inspired by RIFT > work is fine (and normally, whe

Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-20 Thread Tony Przygienda
Yes, acknowledging the idea of negative disaggregation is inspired by RIFT work is fine (and normally, when inspired by an idea at least in research cycles it is considered basic courtesy to refer to the according source, something has been lost more and more in IETF over time I dare to observe

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-09-04 Thread Tony Przygienda
I read the draft since the longish thread triggered my interest. As Peter said very thin ice walking with magic soft-state-timers for (to me) entirely unclear benefit and lots of interesting questions completely omitted like e.g. what will happen if a mix of old and new routers are in the network.

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-21 Thread Tony Przygienda
thanks Les, albeit the authors got already lots of helpful comments from you and Peter over beers in a bar I hope for further discussions. Especially your opinion on a) special case where FR is 1-hop away from the leafs should not need a tunnel. I think most people would agree it's a good thing

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-19 Thread Tony Przygienda
On Fri, Jun 19, 2020 at 12:43 PM John Scudder wrote: > Hi All, > > I just did a full read-through of -01. Without denigrating any other > solutions, I support adoption of this one. > > I do have a few comments and nits, below. > > - Paragraph 2 of section 9 is unclear, IMO; I hope this can be

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-16 Thread Tony Przygienda
support as co-author. not aware of any additional IPR beside the one disclosed on the tracker already thx == t On Wed, Jun 10, 2020 at 12:29 PM Christian Hopps wrote: > This begins a 2 week WG adoption call for the following draft: > >

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread Tony Przygienda
, Jun 15, 2020 at 11:01 AM wrote: > > > On Jun 15, 2020, at 10:56 AM, Tony Przygienda wrote: > > PNNI had transit areas in hierarchy working but the trick was connection > setup cranck-back. Such a thing would work for RSVP or any of the stateful > connection setups but alas, th

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread Tony Przygienda
On Mon, Jun 15, 2020 at 10:37 AM wrote: > > Hi Robert, > > > > > It’s very clear that this is inadequate. > > > > Doesn't this really depend how you architect multiple levels ? Sure you > have some physical topology - but it seems to me that the trick is in > properly laying out levels on top of

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-10 Thread Tony Przygienda
JNPR holds relevant IPR on the draft. We are in the process of disclosing it ASAP thanks -- tony On Wed, Jun 10, 2020 at 12:29 PM Christian Hopps wrote: > This begins a 2 week WG adoption call for the following draft: > >

Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-10 Thread Tony Przygienda
Christian, thanks much for that. As there were already two different threads over last months where a good amount of people/companies expressed their support for the draft to progress as WG item, I don't expect to need to pester them again but maybe more will chime in here ... thanks -- tony On

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

2020-06-10 Thread Tony Przygienda
On Wed, Jun 10, 2020 at 11:04 AM Christian Hopps wrote: > > ... > > > > I also suggest to look up why in PNNI we ended up introducing a special > "L1 equivalent" computation to the peer group leader to validate that it > was actually reachable for correct operation (especially hierarchy >

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

2020-06-10 Thread Tony Przygienda
On Wed, Jun 10, 2020 at 10:29 AM Christian Hopps wrote: > > > > > > > > > Hmmm, AFAIR the implementation of OSPF virtual links was having no > tunnel at all (and that's how I remember I implemented it then). I cite > > Correct, that's why I'm suggesting that any solution without tunnels is >

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

2020-06-10 Thread Tony Przygienda
ok, let's not drag vendor specific stuff in. I shouldn't have brought it up I guess, outside the scope of IETF threads ... thanks --- tony On Wed, Jun 10, 2020 at 10:23 AM wrote: > > Tony, > > > On Jun 10, 2020, at 9:40 AM, Tony Przygienda wrote: > > You do seem to be

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

2020-06-10 Thread Tony Przygienda
On Wed, Jun 10, 2020 at 4:27 AM Christian Hopps wrote: > > > > On Jun 9, 2020, at 10:01 PM, Tony Przygienda > wrote: > > > > Chris (addressing in WG member context you declared), I reply tersely > since we will put more work into the draft once it's adopted (for

Re: [Lsr] Thoughts on the area proxy and flood reflector drafts.

2020-06-09 Thread Tony Przygienda
Chris (addressing in WG member context you declared), I reply tersely since we will put more work into the draft once it's adopted (for which I think you saw a good amount of support in two threads already). I deferred from your email since the chain-terrasteam topology you're showing is simply

[Lsr] Call for WG adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01

2020-06-04 Thread Tony Przygienda
I would like to officially call out for adoption of https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 as WG document At this point in time flood reflection has been implemented and works meeting use case requirements of multiple customers which neither TTZ nor draft-proxy is

Re: [Lsr] Request for Working Group Adoption: Area Proxy

2020-06-04 Thread Tony Przygienda
Since stuff seems to develop its own dynamics obviously I will start another thread for official adoption by WG for https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01 in this thread as well. Further comments below On Thu, Jun 4, 2020 at 9:43 AM wrote: > > ... > > In IS-IS

Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

2020-06-02 Thread Tony Przygienda
On Tue, Jun 2, 2020 at 10:59 AM Loa Andersson wrote: > > > For your draft the registries should be called: > > Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV); and > Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS > reachability, IS Neighbor Attribute, L2 Bundle Member

Re: [Lsr] Question on the early allocation - Re: [IANA #1171772] Early Allocations request for "Area Proxy for IS-IS" - draft-li-lsr-isis-area-proxy-04

2020-06-02 Thread Tony Przygienda
Loa, fair points though I would say adoption is kind of a different kettle of fish than early allocation. RFC7120 does not seem to apply given ISIS registries are under expert review (largely due to historical reasons AFAIS). I watch that with lots of interest since due to customer

Re: [Lsr] Flooding across a network

2020-05-06 Thread Tony Przygienda
This is not a simple let's-build-a-better-mechanism problem, this is an epistemology problem and uneven information diffusion cannot be fixed by magic when dealing with total distributed computation. Traditional Link-state basically only works because we assume an epsilon consistently (correct

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-23 Thread Tony Przygienda
: > Tony, > > Thanks for engaging. > > Please inline [Bruno2] > > > > > > > > *From:* Tony Przygienda [mailto:tonysi...@gmail.com] > *Sent:* Wednesday, April 22, 2020 9:25 PM > *To:* DECRAENE Bruno TGI/OLN > *Cc:* lsr@ietf.org; Les Ginsberg

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-22 Thread Tony Przygienda
On Wed, Apr 22, 2020 at 11:03 AM wrote: > Tony, all, > > > > Thanks Tony for the technical and constructive feedback. > > Please inline [Bruno] > > > > *From:* Tony Przygienda [mailto:tonysi...@gmail.com] > *Sent:* Wednesday, April 22, 2020 1:19 AM &

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-21 Thread Tony Przygienda
neither am I aware of anything like this (i.e. per platform/product flooding rate constants) in any major vendor stack for whatever that's worth. It's simply unmaintanable, point. All major vendors have extensive product lines over so many changing hardware configuration/setups it is simply not

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-18 Thread Tony Przygienda
roughly same experience over couple commercial, heavy-lifting vendors on my side. modulo that implementation in user space internally sometimes manages queues per interface & different queues in/out per ISIS packet types + plays with size of socket buffers across interfaces (don't forget, that's

Re: [Lsr] I,Scope of FIT Capability: a node or a link?

2020-04-06 Thread Tony Przygienda
+1 IGP is NOT an AD scope generic L3 broadcast mechanism ;-) BGP is NOT an world scope generic L3 broadcast mechanism ;-) --- tony On Mon, Apr 6, 2020 at 8:06 AM Les Ginsberg (ginsberg) wrote: > This discussion is interesting, but please do not ignore the considerable > feedback from multiple

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

2020-03-29 Thread Tony Przygienda
e.com.cn; Dongjie (Jimmy) ; > > xie...@chinatelecom.cn; Les Ginsberg (ginsberg) > > ; lsr@ietf.org; Tony Przygienda > > > > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing > > basedVirtual Transport Network > > > > I have

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

2020-03-28 Thread Tony Przygienda
en changed to include sub-TLV 25.* On Sat, Mar 28, 2020 at 5:52 PM Tony Przygienda wrote: > > > On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > >> Tony – >> >> >> >> There are a few misunderstandings in your

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

2020-03-28 Thread Tony Przygienda
On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) wrote: > Tony – > > > > There are a few misunderstandings in your post. > > Let me try to correct them. > > > > RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of > TLVs 22,23,141,222,223. > ack, forgot how l2-bundle

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

2020-03-28 Thread Tony Przygienda
I'm surprised by where this discussion is heading, what prevents you from sticking TLV25 into MT TLVs or actually aren't you contradicting existing standards RFC? First, an L2 link bundle (I assume we talk about 8668 here) is a L3 concept in ISIS since you run an adjacency over it and obviously

Re: [Lsr] LSR Interim Invitations (.ics attached)

2020-03-25 Thread Tony Przygienda
s 10pm Japan/Korea time). Is that too early? > > Thanks, > Chris. > > > On Mar 25, 2020, at 5:56 PM, Tony Przygienda > wrote: > > > > yepp, most appreciated ... I will judiciously put a reject filter on > anything coming from Acee or may automatically script tex

Re: [Lsr] Agenda Posted Re: Link State Routing (lsr) WG Virtual Meeting: 2020-04-02

2020-03-25 Thread Tony Przygienda
f support, I think the direction on flooding parameters is much > more pressing and deserves more time. At the same time, I don’t see a > problem with updates on the drafts as long as the drafts themselves have > been updated. > > > > Thanks, > > Acee > > > > *

Re: [Lsr] LSR Interim Invitations (.ics attached)

2020-03-25 Thread Tony Przygienda
yepp, most appreciated ... I will judiciously put a reject filter on anything coming from Acee or may automatically script text'ing him back if such a message arrives 18 hours later precisely (which should hit his deep sleep timezone nicely) ... if you schedule us into 2nd session that's humanly

Re: [Lsr] Agenda Posted Re: Link State Routing (lsr) WG Virtual Meeting: 2020-04-02

2020-03-24 Thread Tony Przygienda
any chance people can post invite.ics I cn import into my agenda? it's really tedious with the timezones & every group announcing the time in different way ;-) Having said that, if we present this topic we could plug in draft-przygienda-lsr-flood-reflection update preso in case Chris wants to do

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-03-10 Thread Tony Przygienda
Christian Hopps wrote: > > > > On Mar 10, 2020, at 11:22 AM, Tony Przygienda > wrote: > > > > Hey Christian, MaxTX is not that hard to derive since it's basically > limited by the local system and its CPU/prioritization/queing architecture. > > Well so the va

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-03-10 Thread Tony Przygienda
On Tue, Mar 10, 2020 at 9:43 AM wrote: > With regards to punting to TCP, I think that TCP (stacks) enforce packet > ordering. > > i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1 > until you receive packet 2. In the meantime, you cannot use the (N-2) > packets that you did

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-03-10 Thread Tony Przygienda
vers partialSNPInterval. It's > so dependent that one might imagine it would be smart for the receiver to > signal the value to the transmitter so that the transmitter can set Usafe > correctly. > > Thanks, > Chris. > [as WG member] > > > > > > >Les (claws in chec

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread Tony Przygienda
ggestion. > > As this is a local matter there is no interoperability issue, but > certainly documenting a better algorithm is worthwhile. > > > > Les (claws in check  ) > > > > > > *From:* Tony Przygienda > *Sent:* Wednesday, February 19, 2020 11:25 AM > *To:* Les Gin

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread Tony Przygienda
Having worked for last couple of years on implementation of flooding speeds that converge LSDBs some order of magnitudes above today's speeds ;-) here's a bunch of observations 1. TX side is easy and useful. My observation having gone quickly over the -ginsberg- draft is that you really want a

Re: [Lsr] IS-IS Requirements for Area Abstraction (Corrected Alias for ADs)

2020-01-28 Thread Tony Przygienda
please do not co-mingle hierarchical ISIS and flood reduction drafts into this discussion. Albeit seemingly related the ttz/abstract/flood-reflector drafts solve a different, valid problem of multiple large operators that hierachical,flood-reduce cannot solve albeit they can be used @ the same

[Lsr] ISIS flood reflection draft posted ...

2019-11-03 Thread Tony Przygienda
We posted updated https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/ replacing the previous version without -lsr- in it and will present in Singapore. thanks --- tony Abstract: This document provides specification of an optional ISIS extension that allows to create l2

Re: [Lsr] IETF 106 LSR Presentation Slot Requests

2019-10-23 Thread Tony Przygienda
15 mins for https://tools.ietf.org/html/draft-przygienda-flood-reflector-00 please it's new stuff, I expect it to generate good amount of discussion on the mike possibly we'll post an update before cut-off as well thanks --- tony On Wed, Oct 23, 2019 at 9:44 AM Yingzhen Qu wrote: > Hi

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread Tony Przygienda
I'm under the impression the whole discussion got triggered by my rather loose remark during the dinner based on, admittedly, my quite dated implementation experience (with 2 disjoint distributed SPTs to reduce flooding). I realized it seems not clearly spelled out on the thread. So to hopefully

[Lsr] Fwd: [Rift] RIFT-Python flooding reduction feature guide

2019-07-23 Thread Tony Przygienda
I read quickly through it, very readable plain narrative explanation of the IMO best-in-class flood reduction we've in RIFT, implemented and operating today so I'm fwd'ing through to LSR given the lively discussions around the topic these days there as well ... Understandably, the spec is dense

Re: [Lsr] Dynamic flow control for flooding

2019-07-23 Thread Tony Przygienda
ted an acerbic, terse style ;-) > > *From:* Tony Przygienda > *Sent:* Tuesday, July 23, 2019 1:56 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* Tony Li ; lsr@ietf.org > *Subject:* Re: [Lsr] Dynamic flow control for flooding > > > > > > > > It is a mistake to e

Re: [Lsr] Dynamic flow control for flooding

2019-07-23 Thread Tony Przygienda
> > > It is a mistake to equate LSP flooding with a set of independent P2P > “connections” – each of which can operate at a rate independent of the > other. > > > > At least my experience much disagrees with that and such a proposal seems to steer towards slowest receiver in the whole network

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

2019-04-03 Thread Tony Przygienda
On Wed, Apr 3, 2019 at 1:36 AM Robert Raszuk wrote: > Hi Tony, > > > The fact that we use them in a point-to-point fashion today is somewhat > orthogonal, as from > > the routing protocol layer, *we cannot tell* whether an interface is > point-to-point or not, and we > > must be explicitly

Re: [Lsr] IS-IS lite (an aside)..

2019-03-08 Thread Tony Przygienda
Somewhat Apple & Kiwi comparisons all over the place here a bit IMO. Assuming we seem to be talking about ROTH in IP fabrics mainly ... a) Babel was solving wireless mesh problem, extremely different from wired fabrics and Babel as solution was IMO fully justified and superior to suggested ISIS

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-05 Thread Tony Przygienda
On Tue, Mar 5, 2019 at 11:12 AM Robert Raszuk wrote: > > > Slow convergence is obviously not a good thing > > Could you please kindly elaborate why ? > > With tons of ECMP in DCs or with number of mechanism for very fast data > plane repairs in WAN (well beyond FRR) IMHO any protocol *fast

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-05 Thread Tony Przygienda
in practical terms +1 to Peter's take here ... Unless we're talking tons of failures simultaneously (which AFAI talked to folks are not that common but can sometimes happen in DCs BTW due to weird things) smaller scale failures with few links would cause potentially diffused "chaining" of

Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for Prefix Originator" - draft-wang-lsr-ospf-prefix-originator-ext-01

2019-02-21 Thread Tony Przygienda
I read it during some mildly boring phone conference here ;-) I do (unsuprisingly) tend to agree with Mr. Ginsberg here. Putting originator on prefix, well, ok, I understand how people got there instead of having a clean router LSA with its loopback hanging of it (which would be IMO the right

[Lsr] Cross post since it may interest fabric/multicast people to join next weeks' discussion

2019-02-07 Thread Tony Przygienda
Cross-post to other groups given today's RIFT discussion: Despite my long resistance to introduce native multicast into RIFT based on M-OSPF scar tissue ;-) it seems it falls out almost naturally along the lines of RPL after having pushed on it today with Pascal. We would end up with a single

Re: [Lsr] IS-IS over TCP

2018-11-06 Thread Tony Przygienda
> > 2)Your statements regarding existing flooding limitations of IS-IS are > rather dated. Many years ago implementations varied from the base > specification by allowing much faster flooding and contiguous flooding > bursts on an interface in support of fast convergence. There are existing > and

Re: [Lsr] Secdir last call review of draft-ietf-isis-reverse-metric-13

2018-10-04 Thread Tony Przygienda
funny enough, https://tools.ietf.org/html/draft-shen-isis-spine-leaf-ext-06#page-12 by the overlaping author set seems already to circumvent this ;-) On Thu, Oct 4, 2018 at 10:37 AM Barry Leiba wrote: > Reviewer: Barry Leiba > Review result: Ready > > This document is well written and seems

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread Tony Przygienda
On Mon, Aug 27, 2018 at 9:41 AM Huaimo Chen wrote: > Hi Robert, > > > > >Leader election happens automatically and procedures for that are to be > vastly similar to today's DR or DIS election. So with this in mind one may > observe that both OSPF and ISIS are pretty centralized on multiaccess >

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-24 Thread Tony Przygienda
On Fri, Aug 24, 2018 at 1:36 PM wrote: > > Tony, > > as to miscabling: yepp, the protocol has either to prevent adjacencies > coming up or one has to deal with generic topologies. If you don't want to > design miscabling prevention/topology ZTP into protocol (like ROLL or RIFT > did) you have to

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-24 Thread Tony Przygienda
Hey Tony, as to miscabling: yepp, the protocol has either to prevent adjacencies coming up or one has to deal with generic topologies. If you don't want to design miscabling prevention/topology ZTP into protocol (like ROLL or RIFT did) you have to deal with generic graph as you say. I think that

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-24 Thread Tony Przygienda
OK, good, real work. So from some scar tissue here's one question a) we are talking any kind of topology for the solution, i.e. generic graph? and then suggestion for IME realistic, operational MUST requirements b) req a): the solution should support distributed and centralized algorithm to

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-23 Thread Tony Przygienda
On Thu, Aug 23, 2018 at 2:05 AM Peter Psenak wrote: > ... > And to be > completely honest, the requirements are pretty straightforward for > anyone that is familiar with the protocols' operation. > > The signalling is quite simple as often the case, good quality algorithms, especially

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-22 Thread Tony Przygienda
I do think it is a good idea in a sense to somehow outline WHAT problem is being solved via some write-down or mind-melt a) I hope it's captured in the meeting notes but otherwise running the danger of repeating myself, the problem splits along the line of "directed graphs" (basically lattices)

Re: [Lsr] 答复: 答复: Regarding OSPF extension for inter-area topology retrieval

2018-07-25 Thread Tony Przygienda
pretty obvious +1 here --- tony On Tue, Jul 24, 2018 at 3:41 AM Rob Shakir wrote: > +1 to Peter. We should not define fragile solutions within the IETF. > > There are also a multitude of other solutions here already: > > 1) IGP adjacency with one router in each area (at a minimum - probably

Re: [Lsr] Flex Algorithms Drafts

2018-04-12 Thread Tony Przygienda
On Thu, Apr 12, 2018 at 2:52 AM, Acee Lindem (acee) wrote: > Hi Peter, > > Ok - we'll decide during whether to merge during the WG adoption call. It > would be a good LSR experiment for a combined draft if there are no > significant differences between the protocols that would

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

2018-04-07 Thread Tony Przygienda
Given Les chimed in I can't resist either now ;-) Individual musings a bit having done some of the stuff in the past ;-) On Fri, Apr 6, 2018 at 1:06 PM, Les Ginsberg (ginsberg) wrote: > I think this discussion has already gone much too far in the direction of > customized