Subject: [PCN] Explanation of changes in the PCN edge behaviour drafts

From: Tom Taylor <[email-masked]>
Date: Wed, 21 Mar 2012 15:08:38 -0400

All changes apply to both documents except for the change in description 
of the factor U, which is SM-specific.

David, you may not have been aware of the need for item 10. Please 
verify that it is OK.

Hope everyone is happy with the changes. Please note additional fixes 
called out at the end of item 13. I think these can be taken care of in 
AUTH 48.

Changes

1. Added text in the introduction to describe the experiment (requested 
by Pete Resnick).

2. Lower-cased a MUST in the paragraph following the new text, talking 
about the need to fill out a per-hop behaviour template. (Part of an 
attempt to clean out unnecessary RFC 2119 language mentioned by two ADs.)

3. Trivial: replaced all t- and T- names for timers and durations with 
t_ and T_ as suggested by Stephen Farrell to avoid confusion with 
arithmetic operations. (Actually missed a few in the CL draft and will 
have to get them in AUTH 48.)

4. First line of Section 3.2.1: replaced "MUST" with "needs to" for 
metering. Changed "informational note" to "Note" after the bullets (both 
at Pete Resnick's suggestion).

5. Section 3.3, first paragraph, talking about support of flow admission 
and termination mechanisms: changed "A Decision Point MUST support both 
mechanisms, but ..." to "If a Decision Point supports both mechanisms, 
...". (Pete Resnick -- couldn't see any interoperability issue to 
justify the MUST.)

6. Section 3.3.3, talking about failure to receive a response from the 
ingress node. Rewrote in an attempt both to satisfy Pete Resnick's 
concern about over-use of mandatory language and to make the mandatory 
procedures clearer.

OLD

    A centralized Decision Point SHOULD start a timer t-sndFail when it
    sends a request for the estimated value of PCN-sent-rate to a given
    PCN-ingress-node.  If the Decision Point fails to receive a response
    from the PCN-ingress-node before t-sndFail reaches the configurable
    value T-crit, the Decision Point SHOULD repeat the request but MAY
    also use ETM-rate as an estimate of the amount of traffic to be
    terminated in place of the quantity

       PCN-sent-rate - SAR

    specified in Section 3.3.2.  Because this will over-estimate the
    amount of traffic to be terminated due to dropping of PCN-packets by
    interior nodes, the Decision Point SHOULD use multiple rounds of
    termination under these circumstances.  If the second request to the
    PCN-ingress-node also fails, the Decision Point SHOULD notify
    management.

       The use of T-crit is an approximation.  A more precise limit would
       be of the order of two round-trip times, plus an allowance for
       processing at each end, plus an allowance for variance in these
       values.

NEW

    If a centralized Decision Point sends a request for the estimated
    value of PCN-sent-rate to a given PCN-ingress-node and fails to
    receive a response in a reasonable amount of time, the Decision Point
    SHOULD repeat the request once.  While waiting after sending this
    second request, the Decision Point MAY begin selecting flows to
    terminate, using ETM-rate as an estimate of the amount of traffic to
    be terminated in place of the quantity

       PCN-sent-rate - SAR

    specified in Section 3.3.2.  Because ETM-rate will over-estimate the
    amount of traffic to be terminated due to dropping of PCN-packets by
    interior nodes, the Decision Point SHOULD terminate less than the
    full amount ETM-rate in the first pass and recalculate the additional
    amount to terminate in additional passes based on subsequent reports
    from the PCN-egress-node.  If the second request to the PCN-ingress-
    node also fails, the Decision Point MUST select flows to terminate
    based on the ETM-rate approximation as just described and should
    notify management.

       The response timer t_sndFail with upper bound T_crit is specified
       in Section 3.5.  The use of T_crit is an approximation.  A more
       precise limit would be of the order of two round-trip times, plus
       an allowance for processing at each end, plus an allowance for
       variance in these values.

7. Section 3.4, note giving an example of how the PCN-ingress-node does 
its estimate: changed the "MAY" to a "can".

8. Section 3.5, action for expiry of t_sndFail: referred back to Section 
3.3.3 instead of the previous inaccurate summary of a fairly complex 
procedure.

9. Removed all RFC 2119 language from Section 4 (the per-hop behaviour 
section). Originally responding to a comment by Sean Turner that Section 
4.2.1 claimed to paraphrase RFC 5559 but had such language where RFC 
5559 did not. Decided that it wasn't necessary elsewhere in the section, 
either.

10. Based on discussion of the 3-in-1 draft, at Bob Briscoe's request, 
changed section 4.2.1 to focus only on the tunneling option and the 
resulting non-problem with use of ECN bits.

OLD

    Packets at the ingress to the domain are classified as either PCN or
    non-PCN.  Non-PCN packets MAY share the network with PCN packets
    within the domain.  Because the encoding specified in [RFC5696] and
    used in this document requires the use of the ECN fields, PCN-
    ingress-nodes MUST prevent ECN-capable traffic that uses the same
    DSCP as PCN from entering the PCN-domain directly.  The PCN-ingress-
    node can accomplish this in three ways.  The choice between these
    depends on local policy.

    o  ECN-capable traffic MAY be dropped.  This policy is NOT
       RECOMMENDED, since it prevents the proper operation of end-to-end
       ECN as a means of controlling congestion.

    o  ECN-capable traffic MAY be assigned a different DSCP from PCN
       traffic.  This could mean that it is relegated to a lower-priority
       behaviour aggregate.

    o  ECN-capable traffic MAY be tunneled across the PCN-domain.  If
       this is done, the PCN-ingress-node MUST mark packets as either
       not-PCN or PCN-not-marked only after the encapsulation of the
       packet, including any initial setting of the ECN field, has been
       completed.

NEW

    Packets at the ingress to the domain are classified as either PCN or
    non-PCN.  Non-PCN packets can share the network with PCN packets
    within the domain.  The encoding specified in [RFC5696] and used in
    this document requires the use of the ECN fields.  PCN-ingress-nodes
    need to prevent ECN-capable traffic that uses the same DSCP as PCN
    from entering the PCN-domain directly.  This is not an issue when
    tunneling of PCN-packets between the PCN-ingress-node and the PCN-
    egress-node is done, as recommended in Section 5.1.2, provided that
    the original ECN markings of arriving packets are preserved in the
    encapsulated headers.

11. In the next paragraph, originally said that PCN packets of 
non-admitted flows are dropped. Replaced this with "blocked" and a 
backward reference to the definition of blocking in Section 1. 
(Follow-through on comments by Brian Carpenter, fixed elsewhere.

12. Section 4.7: originally said PCN use of ECN bits could interfere 
with the end-to-end use of ECN. Replaced with the following text:

    The PCN CL per-domain behaviour could theoretically interfere with
    the use of end-to-end ECN due to reuse of ECN bits for PCN marking.
    However, this is not a problem in practice because of the need to
    tunnel PCN-packets from ingress to egress (see Section 5.1.2).  The
    encapsulated header can retain the original ECN markings as received
    at the PCN-ingress-node, leaving the ECN bits in the encapsulating
    header fully available for use by PCN.

13. Section 5.1.3, basically editorial rearrangement of text to take 
account of the fact that the ingress node will always perform 
encapsulation. Talking about extensions to the DiffServ MIB.

OLD

    ... The required
    extensions specifically include objects for re-marking the ECN field
    at the PCN-ingress-node and an extension to the classifiers to
    include the ECN field at PCN-interior and PCN-egress-nodes.  In
    addition, the MIB has to be extended to include a potential
    encapsulation action following re-classification by ingress-egress-
    aggregate.  Finally, a new metering algorithm may need to be defined
    at the PCN-interior-nodes to handle excess-traffic-marking.

NEW

    ... The required
    extensions specifically include an encapsulation action following re-
    classification by ingress-egress-aggregate.  In addition, the MIB has
    to be extended to include objects for marking the ECN field in the
    outer header at the PCN-ingress-node and an extension to the
    classifiers to include the ECN field at PCN-interior and PCN-egress-
    nodes.  Finally, new metering algorithms may need to be defined at
    the PCN-interior-nodes to handle threshold-marking and packet-size-
    independent excess-traffic-marking.

*Oops noted* -- that text was taken from the SM document. Have to remove 
the reference to threshold-marking, and have to mark that point 
"[CL-specific]" in the CL document.

*Speaking of oops*: Section 5.1.1 still talks about the operator having 
to decide whether to use tunneling. Should that stay or go?

14. Security consideration added (Section 6), in response to comments by 
two ADs. Section now reads:

    [RFC5559] provides a general description of the security
    considerations for PCN.  This memo introduces one new consideration,
    related to the use of a centralized Decision Point.  The Decision
    Point itself is a trusted entity.  However, its use implies the
    existence of an interface on the PCN-ingress-node through which
    communication of policy decisions takes place.  That interface is a
    point of vulnerability which must be protected from denial of service
    attacks.

15. Fixed reference Mele12, naming the journal in which the article will 
appear.

16. SM-specific change in Section 3.3.2 to improve the description of 
the factor U. The new text reads:

    1.  [SM-specific] The sustainable aggregate rate (SAR) for the given
        ingress-egress-aggregate is estimated using the formula:

           SAR = U * NM-Rate

        for the latest reported interval, where U is a configurable
        factor greater than one which is the same for all ingress-egress-
        aggregates.  In effect, the value of the PCN-supportable-rate for
        each link is approximated by the expression

           U*PCN-admissible-rate

        rather than being calculated explicitly.

---

From: Michael Menth <[email-masked]>
Date: Wed, 21 Mar 2012 22:14:43 +0100

Hi Tom,

> Changes
>
> 1. Added text in the introduction to describe the experiment 
> (requested by Pete Resnick).
* committed bandwidth is strange, you mean the rate of admitted traffic
* link capacity is wrong, this should be admissible rate
* a long duration of the experiment is not needed if pre-congestion is 
caused intentionally

>    be terminated in place of the quantity
Using ETM-Rate instead of (PCN-sent-rate - SAR) may be a correct 
workaround for CL but not for SM! With SM, the PCN traffic rate is 
terminated down to the admissible rate in the absence of traffic loss. 
The approach corresponding to CL would be (NM-Rate + ETM-Rate - SAR).

>       variance in these values.
This works for CL but not for SM, see my previous email!

>    the original ECN markings of arriving packets are preserved in the
Moving the old text to 3-in-1 means that this doc is now aware of 
3-in-1. Therefore, we should base this edge behavior no longer on 
baseline encoding (RFC5696) but on 3-in-1.

> (Follow-through on comments by Brian Carpenter, fixed elsewhere.
I think to remember that 3-in-1 recommended recoloring as preferred 
policing option.

>    classification by ingress-egress-aggregate.  In addition, the MIB 
which MIB?

> has
I do not understand why the defined marking algorithms are not 
sufficient. Also packet-size-independent excess-traffic-marking is 
defined (see 2.4 in RFC5670).

Regards,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: Tom Taylor <[email-masked]>
Date: Wed, 21 Mar 2012 17:47:39 -0400

My comments in turn below, marked with [PTT].

David, we have a technical error in the SM document, introduced in the 
-06 version. Can I update it and resubmit?

Tom Taylor

> * link capacity is wrong, this should be admissible rate

[PTT] That terminology is appropriate once PCN is running, but when you 
are evaluating a network in advance of installing PCN, I don't think you 
can talk about admissible rate.

> * a long duration of the experiment is not needed if pre-congestion is
[PTT] I thought hard about that, then decided operators might not be 
willing to do it. They would be throwing away customer revenue, or at 
least violating the terms of an SLA.
>> concern about over-use of mandatory language and to make the mandatory
...

> This works for CL but not for SM, see my previous email!
[PTT] You are absolutely right. This comes from working on CL first, 
then cutting and pasting. The bad text has been there since the -06 
version. I'll have to back it out to what was there in -05: no 
workaround, just notify management.

> baseline encoding (RFC5696) but on 3-in-1.
[PTT] I don't think we have to, although it might be reasonable. The 
argument is that there is no need for the old text because we are using 
tunneling.
> I think to remember that 3-in-1 recommended recoloring as preferred

[PTT] We agreed on local policy as the answer when discussing Brian 
Carpenter's review comments.
>> classification by ingress-egress-aggregate. In addition, the MIB

[PTT] DiffServ MIB [RFC3289], referenced in the document.
> defined (see 2.4 in RFC5670).
The above passage is talking about whether the DiffServ MIB supports the 
defined marking algorithms, not saying that new algorithms are needed.

---

From: Michael Menth <[email-masked]>
Date: Thu, 22 Mar 2012 00:52:24 +0100

Hi Tom,

Am 21.03.2012 22:47, schrieb Tom Taylor:
> [PTT] That terminology is appropriate once PCN is running, but when 
> you are evaluating a network in advance of installing PCN, I don't 
> think you can talk about admissible rate.
But when you deploy PCN for the sake of an experiment, then you can.

> least violating the terms of an SLA.
But when you want to perform the experiment, then you want to experience 
challenging conditions. Maybe in a testbed to avoid losing revenues.

> argument is that there is no need for the old text because we are 
> using tunneling.
I'd suggest to substitute RFC5696 by 3-in-1 in general to avoid 
confusion by a soon obsoleted RFC.

> [PTT] DiffServ MIB [RFC3289], referenced in the document.
ok, now I see the reference was some sentences before

> The above passage is talking about whether the DiffServ MIB supports 
> the defined marking algorithms, not saying that new algorithms are 
> needed.
ok, understand

Regards,

     Michael

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 22 Mar 2012 22:57:21 +0000

Tom,

inline tagged [BB]...

>>>>the original ECN markings of arriving packets are preserved in the

[BB] Section 5.1.2 doesn't actually recommend tunnelling, at least 
not in normative language. All it says is:
"                               As a result, the only way to construct
    such filters reliably is to tunnel the packets from the PCN-ingress-
    node to the PCN-egress-node.
"
In fact we shouldn't only receommend tunnelling, because that's not 
actually true. One could implement CL-PCN by layering rather than 
tunneling. This would work if PCN edge-nodes were the only IP-aware 
nodes in the PCN domain, and PCN metering & marking was done at the 
lower layer (e.g. MPLS) on interior nodes.

This would affect the assumed core network behaviour too. At the 
start of S.2. I suggest a sentence such as:

OLD:
"  This section describes the assumed behaviour for PCN-interior-nodes
    in the PCN-domain.
"
SUGGESTED:
"  This section describes the assumed behaviour for IP-aware PCN-interior-nodes
    in the PCN-domain.
"

And add at end of Section 2:
"An alternative would be to use PCN in MPLS on interior nodes. In 
this case all references to the PCN encoding for IP [3-in-1] would be 
replaced by references to the PCN encoding for MPLS described in 
Appendix A of [RFC5129] (Appendix C of [3-in-1] also gives useful 
examples of the PCN encoding in MPLS). In the rest of this document 
IP-aware interior nodes are assumed. "

In addition, we should state in the introduction (and possibly the 
abstract) that this doc assumes IP-aware PCN nodes, but MPLS interior 
nodes are briefly discussed as an alternative.

It may help to call these edge-behaviours CL-IP and SM-IP, not just 
CL & SM. Then later someone could produce near-identical copies of 
these RFCs called CL-MPLS and SM-MPLS (the latter makes more sense 
than the former because of codepoint restrictions). These wouldn't 
use tunnelling, and would refer to a different encoding, but would 
otherwise be fairly identical.

[Another alternative is to use Layer 3 Ethernet switches as interior 
nodes. L3 switches do forwarding on Ethernet addresses, but they can 
bury into the IP header in the payload for the Diffserv & ECN fields 
(Microsoft has deployed ECN-marking on Layer-3 switches within its 
data centres). However, there's no need to mention an Ethernet option 
in the docs - it's a can-of-worms for standards because some see it 
as a layering violation. This little aside was for the list, not the doc.]

>>[PTT] I don't think we have to, although it might be reasonable. 
>>The argument is that there is no need for the old text because we 
>>are using tunneling.

[BB] I agree. I believe the edge-behaviours and 3-in-1 are all going 
through together so it would be wrong to refer to a doc that 3-in-1 
obsoletes. The RFC-Editor will substitute the appropriate RFCxxxx for 
3-in-1, which will be a normative reference.

I'm afraid you will also need to substitute the new names for the two 
marked codepoints (PM->ETM & EXP->ThM), but SM will only need one (ETM).

>>Carpenter's review comments.

[BB] There's a distinction needed between:
i) treatment of packets of a flow that has asked to be admitted but 
been blocked and
ii) packets where there has never been a request for their flow to be 
admitted, but they happen to be using a PCN-compatible DSCP and an 
ECN-capable codepoint.

For case (i) it would be perfectly reasonable to drop, but re-marking 
the DSCP would also be a reasonable policy.
For case (ii) drop would be unreasonable, because these packets just 
happen to be using a PCN codepoint outside the PCN domain, but 
they're not PCN-traffic. PCN nodes have no business interfering with 
non-PCN traffic. However they've got to do something to prevent 
confusion. So the safest action is to re-mark the DSCP.

If the behaviour for (i) & (ii) are different this could be awkward, 
because it means the PCN-ingress has to remember all the flows it has 
blocked in order to treat them differently from packets that never 
asked to be admitted. How long does it remember blocked flows for?

So a sensible policy would be to treat both (i) & (ii) the same to 
save having to remember blocked flows. But from a standards 
viewpoint, we should still make the distinction, because the 
treatment of each should be a policy choice, not something we should prejudge.

The edge-behaviour docs are the right place to deal with case (i), 
but for the latter case both edge-behaviour docs need to refer to the 
new Section 5.1 of [3-in-1]. The logic here is that edge-behaviours 
deal with flow-related stuff, while 3-in-1 deals with individual 
packets. [3-in-1] refers to the edge-behaviours for handling packets 
of signalled flows.

The split between specs here is unfortunate, but necessary.

>>>>encapsulation.

[BB] Again, there may need to be some reference to layering as an 
alternative to tunnelling.

>>>>Talking about extensions to the DiffServ MIB.
>>>>
>>>>OLD
>>>>
>>>>... The required
>>The above passage is talking about whether the DiffServ MIB 
>>supports the defined marking algorithms, not saying that new 
>>algorithms are needed.
>ok, understand

[BB] The text is still misleading. We on the list only understand 
because you've explained on the list. Perhaps:

s/Finally, new metering algorithms may need to be defined/
  /Finally, new MIB entries for the metering algorithms may need to be defined/

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Tom Taylor <[email-masked]>
Date: Fri, 23 Mar 2012 07:34:47 -0400

I'm left wondering what to do with all these remarks, given that we have 
passed not only WGLC but also IESG approval. I will await AD direction. 
The most I can do at this point is surmise that I have erred as editor 
and some of my changes should be backed out.

On 22/03/2012 6:57 PM, Bob Briscoe wrote:
> [BB] Section 5.1.2 doesn't actually recommend tunnelling, at least not
> in normative language. All it says is:
> This would affect the assumed core network behaviour too. At the start
> of S.2. I suggest a sentence such as:
>
> OLD:
> "An alternative would be to use PCN in MPLS on interior nodes. In this
> case all references to the PCN encoding for IP [3-in-1] would be
> It may help to call these edge-behaviours CL-IP and SM-IP, not just CL &
> SM. Then later someone could produce near-identical copies of these RFCs
> called CL-MPLS and SM-MPLS (the latter makes more sense than the former
> because of codepoint restrictions). These wouldn't use tunnelling, and
> would refer to a different encoding, but would otherwise be fairly
> identical.
>
> (Microsoft has deployed ECN-marking on Layer-3 switches within its data
> centres). However, there's no need to mention an Ethernet option in the
> docs - it's a can-of-worms for standards because some see it as a
> layering violation. This little aside was for the list, not the doc.]
>
>
> i) treatment of packets of a flow that has asked to be admitted but been
> blocked and
> happen to be using a PCN codepoint outside the PCN domain, but they're
> not PCN-traffic. PCN nodes have no business interfering with non-PCN
> traffic. However they've got to do something to prevent confusion. So
> the safest action is to re-mark the DSCP.
>
> blocked in order to treat them differently from packets that never asked
> to be admitted. How long does it remember blocked flows for?
>
> So a sensible policy would be to treat both (i) & (ii) the same to save
> having to remember blocked flows. But from a standards viewpoint, we
> should still make the distinction, because the treatment of each should
> be a policy choice, not something we should prejudge.
>
> The edge-behaviour docs are the right place to deal with case (i), but
> for the latter case both edge-behaviour docs need to refer to the new
> Section 5.1 of [3-in-1]. The logic here is that edge-behaviours deal
> with flow-related stuff, while 3-in-1 deals with individual packets.
> [3-in-1] refers to the edge-behaviours for handling packets of signalled
> flows.
>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 23 Mar 2012 20:06:04 +0000

Tom,

* The rephrasing of the experiments and MIBs text is editorial trivia 
- up to you whether to listen - but the sort of thing that is often 
handled during AUTH48.

* Replacing references to obsoleted RFC5696 will have to be dealt 
with during RFC-Editor stage anyway, but as the changes are quite 
extensive, it will be worth having the WG check them.

* The ingress behaviour issue can largely be solved by keeping the 
text about flow-policing in these docs but referring out for 
packet-policing: to the new ingress behaviour text in 3-in-1. (On 
this point I did email you on 3-Mar, and re-sent two reminders since. 
But I admit the other points are new.)

* The issue that is most serious is allowing for MPLS as well as IP. 
I've realised it potentially affects 3-in-1 too, but less so (because 
3-in-1 defines itself as the encoding for IP). Sorry about this, such 
an important point, but it only just struck me.

I suggest we take AD direction on just the last point (if you are 
willing to take the other stuff in your stride).

Bob

(Ditto, now that the IESG has no more discusses with 3-in-1, I'm 
getting more WG comments than ever. But at least they are quite benign.)

At 11:34 23/03/2012, Tom Taylor wrote:
>I'm left wondering what to do with all these remarks, given that we 
>have passed not only WGLC but also IESG approval. I will await AD 
>direction. The most I can do at this point is surmise that I have 
>erred as editor and some of my changes should be backed out.
>

---

From: <[email-masked]>
Date: Fri, 23 Mar 2012 21:44:44 +0000

Hi Bob,

Regarding the rephrased text:
Police - drop or re-mark to a lower-priority behaviour aggregate
      i) packets received with a DSCP indicating PCN transport that do not
      belong to an admitted flow and ii) packets that are part of a flow
      that asked to be admitted as a PCN-flow but was rejected.

Why should we emphasize the it should be remarked to a lower-priority behaviour aggregate?

Is it acceptable to rephrase the text in the following way (another instead of low-priority):
Police - drop or re-mark to another behaviour aggregate
      i) packets received with a DSCP indicating PCN transport that do not
      belong to an admitted flow and ii) packets that are part of a flow
      that asked to be admitted as a PCN-flow but was rejected.

Best regards,
Georgios

________________________________________
Van: [email-masked] [[email-masked]] namens Bob Briscoe [[email-masked]]
Verzonden: vrijdag 23 maart 2012 21:06
Aan: Tom Taylor
CC: pcn
Onderwerp: Re: [PCN] Explanation of changes in the PCN edge behaviour  drafts

Tom,

Bob

>>/Finally, new MIB entries for the metering algorithms may need to be

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 24 Mar 2012 10:42:11 +0000

Georgios,

Indeed. I would have rather said *another* BA, not a *lower* BA. 
However, that would have changed rather than just clarified what 
RFC5559 originally said. Then it would probably not be allowed as an 
erratum and would instead require an update to the architecture RFC.

Ie., the proposed wording is not ideal, but it's expedient. I'd 
rather not risk the delay that would result if the erratum were rejected.

Cheers

Bob

BTW, I've changed the subject line to the thread I think this was 
intended to be part of - you had replied to one thread but talked 
about another.

At 21:44 23/03/2012, [email-masked] wrote:
>From: <[email-masked]>
>To: <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>
>Subject: RE: [PCN] Explanation of changes in the PCN edge behaviour  drafts
>Thread-Topic: [PCN] Explanation of changes in the PCN edge behaviour  drafts
>Thread-Index: AQHNCTBy2u6oElcMeEuLAQY5k35KpJZ4aG96
>Date: Fri, 23 Mar 2012 21:44:44 +0000
>Message-ID: <[email-masked]>
>References: <[email-masked]>
>         <[email-masked]> 
> <[email-masked]>
>         <[email-masked]>
>         <[email-masked]>
> 
><[email-masked]>,<[email-masked]>
>In-Reply-To: <[email-masked]>
>
>Hi Bob,
>