Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00.

From: John Schiel <[email-masked]>
Date: Mon, 4 Feb 2013 23:45:32 -0700

On Mon, Jan 28, 2013 at 6:30 PM, David Farmer <[email-masked]> wrote:
> On 1/28/13 19:03 , Jeff Wheeler wrote:
>>
>> On Mon, Jan 28, 2013 at 3:33 PM, David Farmer <[email-masked]> wrote:
>>>
>>> This creates a knob, and I really don't like that, but honestly there are
>>> implementations that DO NOT conform with the "when received, any value
>>> MUST
>>> be accepted" clause, and we have to deal with, at least for now.  So,
>>> while
>>> I think creating knobs should be avoided, I'm not sure it can
>>> realistically
>>> be avoided in this case, and with the implementations that are in the
>>> wild
>>> today.
>>
>>
>> I always like options/knobs but I doubt your suggestion will be popular.
>>
>> Why do you think propagate-as-received should be the default behavior?
>
>
> The argument is in the intro of the draft;
>
>    The real issue is that reserved flags are only useful if there is
>    some hope of someday using them for something.  If implementations
>    reset these flags on propagation, then a future revision to the BGP
>    specification which introduces a new flag will not be able to
>    propagate the new attribute flag end to end, since it would be very
>    likely that some well-meaning intermediate router would zero on it.
>    The effort to roll out implementations that transited the new flag
>    would almost certainly be prohibitive.
>
> The compromise is require all conforming implementations to at least support
> propagate-as-received as an option.  It doesn't completely eliminate the
> issue described in the intro, but at least there is still some minimal hope
> of being able to implement new flags some day. Especially, since it should
> be clear that propagate-as-zero is really just a transition, and maybe in
> some future revision it could be removed once any-value-MUST-be-accepted is
> more or less universally implemented. One can hope, at least I link that
> better than "the bits are dead".
>
> What do others think?
>
David I like your suggestion. While not optimal as it does add another
knob, it does give the operator the choice on how to deal with these
bits and implement a configuration that is expected between the
different router makers and versions of code.

--John

>
> --
> ================================================
> David Farmer               Email: [email-masked]
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 5 Feb 2013 07:40:42 -0500

> The argument is in the intro of the draft;
...
> be clear that propagate-as-zero is really just a transition, and maybe in

I might agree if John & Susan's draft was honest about the fact that
this is a CHANGE in behavior.  However, they have instead claimed it
is a "clarification."  That is really not true and it is an important
distinction!

As far as I am aware, no one is proposing a use for these bits.  I
agree that they cannot ever be used without an end-to-end agreement
not to zero them out, but it's hard to imagine that it will become
"safe" to do this unless someone is willing to originate routes to the
DFZ with these bits set, label it an experiment, and break a
significant portion of the Internet until networks affected by the
didn't-ignore bug update their code.

If there was any proposal to use the bits, one would also be changing
the language that forbids setting the reserved bits or requires the
implementation to ignore the bits on receipt.  Notice that they are
NOT changing those things.

If they really want to apply this change to BGP then they should admit
it is a change and request a BGP Capability Code so it is negotiated.
The entire goal of the proposal seems to be to allow Juniper to avoid
repairing a bug or even admitting that they have a bug, so I think it
is unlikely that they will update their draft, get a cap code, write
software to implement it, and add a knob to the Juniper UI.

So far there has been no reasonable argument supporting their draft,
unless you think "I didn't understand what send meant and now I don't
want to change my code" is a reasonable justification for changing
standardized language that is 20 years old.

You know why I oppose this change?  Because it is being mis-labeled a
clarification, because there is no proposed utility to the change (no
use for the bits), and because it is virtually guaranteed that any
routes announced to the DFZ this way today would still break networks
and cost money.  That's a pretty good reason to reject their idea.

They are welcome to prove me wrong.
-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 5 Feb 2013 11:15:46 -0500

Jeff and Dave:

Due to the fact I was there when we draft the text, I called it a
clarification.  However, my view of history may make it unclear to others.  

I will update the draft to the word "change".  Are you also a supporter of
signaling this change with an OPEN option so it can be negotiated?

Sue Hares

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff
Wheeler
Sent: Tuesday, February 05, 2013 7:41 AM
To: David Farmer
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

...
> issue described in the intro, but at least there is still some minimal 
> hope of being able to implement new flags some day. Especially, since 
> it should be clear that propagate-as-zero is really just a transition, 
> and maybe in

I might agree if John & Susan's draft was honest about the fact that this is
a CHANGE in behavior.  However, they have instead claimed it is a
"clarification."  That is really not true and it is an important
distinction!

As far as I am aware, no one is proposing a use for these bits.  I agree
that they cannot ever be used without an end-to-end agreement not to zero
them out, but it's hard to imagine that it will become "safe" to do this
unless someone is willing to originate routes to the DFZ with these bits
set, label it an experiment, and break a significant portion of the Internet
until networks affected by the didn't-ignore bug update their code.

If there was any proposal to use the bits, one would also be changing the
language that forbids setting the reserved bits or requires the
implementation to ignore the bits on receipt.  Notice that they are NOT
changing those things.

If they really want to apply this change to BGP then they should admit it is
a change and request a BGP Capability Code so it is negotiated.
The entire goal of the proposal seems to be to allow Juniper to avoid
repairing a bug or even admitting that they have a bug, so I think it is
unlikely that they will update their draft, get a cap code, write software
to implement it, and add a knob to the Juniper UI.

So far there has been no reasonable argument supporting their draft, unless
you think "I didn't understand what send meant and now I don't want to
change my code" is a reasonable justification for changing standardized
language that is 20 years old.

You know why I oppose this change?  Because it is being mis-labeled a
clarification, because there is no proposed utility to the change (no use
for the bits), and because it is virtually guaranteed that any routes
announced to the DFZ this way today would still break networks and cost
money.  That's a pretty good reason to reject their idea.

---

From: Enke Chen <[email-masked]>
Date: Tue, 05 Feb 2013 10:32:26 -0800

Hi, folks:

Clearly there are different implementations in the field because of the 
ambiguity. I do not think it would be feasible to mandate one behavior 
over another (after 20 years).  It might be useful, however, to document 
the differences in behavior, and warn coders about not resetting the 
session.

  -- Enke

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 5 Feb 2013 14:20:39 -0500

> signaling this change with an OPEN option so it can be negotiated?

I assume you mean a Capability Code will be used to indicate a
receiver's willingness to accept non-zero reserved Attribute Flags
bits.

I support that idea if it is also standardized that any router
announcing such Capability promises NOT to send non-zero reserved
bits, if the BGP neighbor did not also advertise the Capability.  This
means that any vendor who wants to use the bits can do so safely, and
a vendor who wants to implement that feature will definitely fail-safe
if his neighboring router might mis-handle the bits (fail to IGNORE.)

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 6 Feb 2013 00:11:34 +0000

If you want to use the bits in a new feature, you can only do it to signal something to the neighbor router, not to have it propagate to further routers. There is a large installed base of routers many of which will not be upgraded for many years or ever. You can not assume that these bits will make it further than one hop.

--
Jakob Heitz.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 7 Feb 2013 13:16:07 -0500

Jeff:

Thank you for the indication of the support of the capability code. 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff
Wheeler
Sent: Tuesday, February 05, 2013 2:21 PM
To: Susan Hares
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

On Tue, Feb 5, 2013 at 11:15 AM, Susan Hares <[email-masked]> wrote:
> I will update the draft to the word "change".  Are you also a 
> supporter of signaling this change with an OPEN option so it can be
negotiated?

I assume you mean a Capability Code will be used to indicate a receiver's
willingness to accept non-zero reserved Attribute Flags bits.

I support that idea if it is also standardized that any router announcing
such Capability promises NOT to send non-zero reserved bits, if the BGP
neighbor did not also advertise the Capability.  This means that any vendor
who wants to use the bits can do so safely, and a vendor who wants to
implement that feature will definitely fail-safe if his neighboring router
might mis-handle the bits (fail to IGNORE.)

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 7 Feb 2013 19:20:06 +0000

This works but only if the announcer is saying "I support the use of those bits AND all of my peers do" or "I support the use of those bits AND won't propagate to peers that don't support the use of those bits".

Otherwise you support it, I support it but some of my peers don't and when I advertise those to them unmodified they fail.

Right?

(coffee != sleep) & (!coffee == sleep)
 [email-masked]<mailto:[email-masked]>
________________________________
From: [email-masked] [[email-masked]] on behalf of Susan Hares [[email-masked]]
Sent: Thursday, February 07, 2013 11:16 AM
To: 'Jeff Wheeler'
Cc: 'idr wg'
Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00.

Jeff:

Sue

-----Original Message-----

negotiated?

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 7 Feb 2013 14:26:36 -0500

Donald

Yes. To be precise. 

Peer A----Peer-B  if both support, then it works.

Peer-A-peer-B-Peer-c Only if all peers support. 

If peering A-B and not see, no support yes.  Therefore, If I am B and I want
this to work - I refuse A & C unless on. It becomes a configuration.
Iteration out.  Networks can adopt this configuration flag to assure
themselves this bug won't happen. 

If you want to mix and match, then community flags could be set.  However,
general community support is there.  If we want to establish a "well-known"
community, it is possible; but I would prefer to have actual use dictate
that. 

Sue 

 

From: Smith, Donald [mailto:[email-masked]] 
Sent: Thursday, February 07, 2013 2:20 PM
To: Susan Hares; 'Jeff Wheeler'
Cc: 'idr wg'
Subject: RE: [Idr] 2 week WG adoption & LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

This works but only if the announcer is saying "I support the use of those
bits AND all of my peers do" or "I support the use of those bits AND won't
propagate to peers that don't support the use of those bits".

Otherwise you support it, I support it but some of my peers don't and when I
advertise those to them unmodified they fail.

Right?

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

  _____  

From: [email-masked] [[email-masked]] on behalf of Susan Hares
[[email-masked]]
Sent: Thursday, February 07, 2013 11:16 AM
To: 'Jeff Wheeler'
Cc: 'idr wg'
Subject: Re: [Idr] 2 week WG adoption & LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

Jeff:

Sue 

-----Original Message-----

negotiated?

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 7 Feb 2013 14:30:18 -0500

Ignore earlier text.. (sigh.. obviously I need more coffee today). 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan
Hares
Sent: Thursday, February 07, 2013 2:27 PM
To: 'Smith, Donald'; 'Jeff Wheeler'
Cc: 'idr wg'
Subject: Re: [Idr] 2 week WG adoption & LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

Donald

Yes. To be precise. 

If peering A-B and C .  Therefore, If I am B and I want this to work - I
refuse A & C unless flag bit on. 

Therefore, it becomes a configuration issue.  Networks can adopt this
configuration flag to assure themselves this bug won't happen. 

If you want to track this in UPDATEs,  then you could use community flags.
If we want to establish a "well-known" community, it is possible; but I
would prefer to have actual use dictate that. 

Sue 

 

Right?

  _____  

Jeff:

Sue 

-----Original Message-----

negotiated?

---

From: John Schiel <[email-masked]>
Date: Fri, 8 Feb 2013 00:00:41 -0700

> If peering A-B and C .  Therefore, If I am B and I want this to work – I
> configuration flag to assure themselves this bug won’t happen.
>
>
>
> If we want to establish a “well-known” community, it is possible; but I

I just read Capabilities Advertisement with BGP-4
http://tools.ietf.org/html/rfc5492 and it states the Capability is for
an OPEN. If that is true, then an UPDATE could break things and we
would be back to where we are today correct?

If I understand RFC5492 correctly and what Jeff has proposed, if the
Capability is not accepted on an OPEN, then if the peers agree not to
use that Capabiity, then the sending router must zero out the bits.
Correct?

--John

---

From: Jeff Wheeler <[email-masked]>
Date: Fri, 8 Feb 2013 03:55:17 -0500

> would be back to where we are today correct?

The underlying problem is with bits in Path Attributes, which are
always carried by UPDATE messages.

Capabilities are advertised (negotiated) in OPEN messages because
capabilities are established at the beginning of a BGP session, and
remain the same throughout the lifetime of that session.

For example, if you send Capability 1 and your neighbor also sends
Capability 1, then the BGP session supports MP-BGP updates.  This
means, for example, you can receive MP_REACH_NLRI and MP_UNREACH_NLRI
Attributes in UPDATE messages, and they may contain NLRI of IPv6,
various VPN AFIs, labeled-unicast next-hops, or whatever.  Of course
the specific address families supported by an MP-BGP session are
further negotiated by data in the capability value.

> use that Capabiity, then the sending router must zero out the bits.

You've understood my proposal correctly, yes.

The underlying issue here is some folks really want a "solution" that
allows them to avoid saying their code was at fault for outages that
their customers experienced.

My idea gives them that solution by couching the "fix" -- them
changing their code to begin zeroing out the bits -- in a
capability-negotiated feature.  The ambiguous language in the base
specification for BGP can be left alone and vendors can continue to
blame it if customers cry.  But they can also say, look, customer, if
you upgrade to RainbowOS 13, we have this new "feature" that prevents
the problem from happening.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 8 Feb 2013 06:22:20 -0500

+1 on this description of problem/solution. 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff
Wheeler
Sent: Friday, February 08, 2013 3:55 AM
To: John Schiel
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

> would be back to where we are today correct?

The underlying problem is with bits in Path Attributes, which are always
carried by UPDATE messages.

Capabilities are advertised (negotiated) in OPEN messages because
capabilities are established at the beginning of a BGP session, and remain
the same throughout the lifetime of that session.

For example, if you send Capability 1 and your neighbor also sends
Capability 1, then the BGP session supports MP-BGP updates.  This means, for
example, you can receive MP_REACH_NLRI and MP_UNREACH_NLRI Attributes in
UPDATE messages, and they may contain NLRI of IPv6, various VPN AFIs,
labeled-unicast next-hops, or whatever.  Of course the specific address
families supported by an MP-BGP session are further negotiated by data in
the capability value.

The underlying issue here is some folks really want a "solution" that allows
them to avoid saying their code was at fault for outages that their
customers experienced.

My idea gives them that solution by couching the "fix" -- them changing
their code to begin zeroing out the bits -- in a capability-negotiated
feature.  The ambiguous language in the base specification for BGP can be
left alone and vendors can continue to blame it if customers cry.  But they
can also say, look, customer, if you upgrade to RainbowOS 13, we have this
new "feature" that prevents the problem from happening.

---

From: David Farmer <[email-masked]>
Date: Fri, 08 Feb 2013 12:20:09 -0600

On 2/8/13 02:55 , Jeff Wheeler wrote:
....
> the problem from happening.

I'm fine with the capability-negotiation solution you propose, it  would 
basically determine if you "propagate as received" or "propagate as 
zero".  However, one part of the current language should not be left 
alone.  "When received, any value MUST be accepted", should be included 
as an explicit clarification of the current specification.

While the intent of the current language, with regards to how to 
propagate these bits is ambiguous, I believe "When received, any value 
MUST be accepted" is implied in the current specification.  Making it 
explicit is a valid clarification that needs to be made, and should be 
the expected behavior regardless of support for the capability you are 
proposing.

Negotiating if it is safe to "propagate as received" is a change in the 
spec and more than just a clarification.  Making it clear that the 
expected behavior is "propagate as zero", unless the capability has been 
negotiated.

So, future deployment of any features that requires the use of the 
currently unused bits would require the new capability being proposed 
here be widely deployed and support even by implementations that do not 
directly support the future new feature that would use the bits. 
Therefore, I believe we should fix this now to allow implementation and 
deployment of code that can safely allow future use of the unused bits, 
well before any proposed use of the bits themselves.

By the way, what is the status of this draft?  I would respectfully 
suggest that call for WG adoption gained consensus and the WGLC did not, 
but that not my call.  Chairs?

Thanks.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 8 Feb 2013 13:31:13 -0500

+1 (to what David wrote).

Brian

On Fri, Feb 8, 2013 at 1:20 PM, David Farmer <[email-masked]> wrote:

> basically determine if you "propagate as received" or "propagate as zero".
>  However, one part of the current language should not be left alone.  "When
> received, any value MUST be accepted", should be included as an explicit
> clarification of the current specification.
>
> While the intent of the current language, with regards to how to propagate
> these bits is ambiguous, I believe "When received, any value MUST be
> accepted" is implied in the current specification.  Making it explicit is a
> valid clarification that needs to be made, and should be the expected
> behavior regardless of support for the capability you are proposing.
>
> spec and more than just a clarification.  Making it clear that the expected
> behavior is "propagate as zero", unless the capability has been negotiated.
>
> currently unused bits would require the new capability being proposed here
> be widely deployed and support even by implementations that do not directly
> support the future new feature that would use the bits. Therefore, I
> believe we should fix this now to allow implementation and deployment of
> code that can safely allow future use of the unused bits, well before any
> proposed use of the bits themselves.
>
> ==============================**==================
> ==============================**==================
> ______________________________**_________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>
>

---

From: Jeff Wheeler <[email-masked]>
Date: Fri, 8 Feb 2013 14:23:20 -0500

> behavior regardless of support for the capability you are proposing.

I can buy into your suggestion, "When received, any value MUST be
accepted."  Can that be accomplished using the errata process?

> By the way, what is the status of this draft?  I would respectfully suggest
> that call for WG adoption gained consensus and the WGLC did not, but that
> not my call.  Chairs?

I do not know how the IETF process works.  The draft, in its current
form, does what I think is the opposite of good.  I believe Susan has
warmed to my suggestion that a capability should be used, and behavior
in absence of this capability from a neighbor must be to zero-out the
bits.  This seems like a huge departure from its original intent.

I really did not know how little understanding there is of this
problem by some folks on the list.  I have made some slides that may
be helpful:
http://inconcepts.biz/~jsw/bgp_attrib_flags_problem.pdf
Included are diagrams of the BGP Path Attribute header on slides #5
and #6.  If you don't have 30 minutes to go through the whole file,
just read those slides.

The reason I made these is I am absolutely shocked by some of the
off-list mail I have got from a couple of people who have posted as if
they understand this problem, and they do not know what happened that
broke the DFZ, why, etc.  Frankly I think if people want to express an
opinion about this topic, that is fine, but anyone doing so should
spend a little time understanding the problem so they can form an
educated opinion!

I have received questions about how this problem could be tested or
reproduced, what equipment would be needed, etc. and I am happy to
answer these questions, but I do not think people that do not already
know this should be advocating a position on this matter -- they
should first understand the problem so they can decide what their
position should be!

Just to clear up how to reproduce the problem, by the way (and PLEASE
DO NOT DO THIS IN THE DFZ BECAUSE IT WILL BREAK NETWORKS), all you
need to do is advertise a route to an older OpenBGPd, Alcatel, or
other router that fails to ignore the reserved bits, and instead,
closes the BGP session.  There is a diagram on slide#6 that shows the
structure of the BGP Path Attribute header needed to do this
(obviously it can work for any path attribute type, not just
Aggregator.)  You can advertise such a route trivially by just
modifying any open-source BGP speaker or your own company's
implementation, or spending 1 hour writing a very basic BGP speaker
just for this purpose.

Again, please, do not reproduce this problem on the DFZ.  If you are
going to reproduce this I would suggest your announcement should be an
RFC1918 prefix just in case.  No kidding, if you send routes out like
this today, it will break some very big networks and cost "the
Internet" a lot of money, and some vendors will have to endure more
wrath from angry customers.

If any vendor needs help with test code to reproduce this, I would be
happy to assist; but it is so basic, your own programmers can
definitely do it.  I have provided all the information they need
(several times) and now it is in slide-show form.

Finally, I really am shocked that people on this list are advocating a
position and writing text to modify the BGP specification without
understanding this problem, or even its scope.  I am not going to
forward off-list mails, but these people are advocating a dangerous
and foolish modification to BGP without spending some time to
understand the problem or the ramifications of own suggestions.  This
is an irresponsible way to forge policy and it is exactly why the
operator community is disdainful of the IETF -- because operators
generally think "IETF people" are a bunch of policy hawks who don't
understand our problems.  Sometimes that belief is right.

If anyone thinks they might not understand the issue, please, contact
me off-list.  Email, phone, smoke signals, whatever.  You're going to
get my opinion, but you can seek other opinions within your company or
from others on this list, and form your own view.  At the very least,
if you have a discussion about it with me, I assure you that you will
have a more thorough understanding of the issue, whether or not you
end up agreeing with my opinion about what solutions are most
practical.

Thanks

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 8 Feb 2013 15:39:00 -0500

Brian and David: 

I agree that the WG adoption did work; and the WGLC did not.   

The authors (being chairs) will respin the draft and send it out for more
debate.   This author has been gathering lots of public and private debate
points. I want to thank everyone for all their comments.  

I've got a few more private emails to work through prior to releasing a new
version of the draft.  Then I'll summarize our discussion and post the
draft. 

Thanks for the candid nature of the debate. 

Sue 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian
Dickson
Sent: Friday, February 08, 2013 1:31 PM
To: David Farmer
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

Brian

Negotiating if it is safe to "propagate as received" is a change in the spec
and more than just a clarification.  Making it clear that the expected
behavior is "propagate as zero", unless the capability has been negotiated.

So, future deployment of any features that requires the use of the currently
unused bits would require the new capability being proposed here be widely
deployed and support even by implementations that do not directly support
the future new feature that would use the bits. Therefore, I believe we
should fix this now to allow implementation and deployment of code that can
safely allow future use of the unused bits, well before any proposed use of
the bits themselves.

Thanks.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 15 Feb 2013 20:35:58 -0500

<co-chair hat off>

Sorry to reply to this so late:

On Feb 5, 2013, at 7:40 AM, Jeff Wheeler <[email-masked]> wrote:

> repairing a bug or even admitting that they have a bug

This was not the goal, regardless of how it seemed to you. I won't reply individually to any of your other notes making similar claims, but the same applies to them.

I see that the conversation has gone down more constructive paths subsequently. I appreciate that and won't belabor the point further but will instead focus on contributing to the actual work. Let's get the protocol right, where the meaning of "right" is the result of a fuzzy multi-variable calculation and debate, but not one that includes saving face (for my employer or anyone else's) as an input. 

Thanks,

--John