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

[Bob Briscoe <[e-mail]>]

Tom,

inline tagged [BB]...

At 23:52 21/03/2012, Michael Menth wrote:
>Hi Tom,
>Am 21.03.2012 22:47, schrieb Tom Taylor:
>>My comments in turn below, marked with [PTT].
>>On 21/03/2012 5:14 PM, Michael Menth wrote:
>>>Hi Tom,
>>>
>>>>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.

[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.]


>>>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.
>>[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'd suggest to substitute RFC5696 by 3-in-1 in general to avoid 
>confusion by a soon obsoleted RFC.

[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).



>>>>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.
>>>I think to remember that 3-in-1 recommended recoloring as preferred
>>>policing option.
>>
>>[PTT] We agreed on local policy as the answer when discussing Brian 
>>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.


>>>>13. Section 5.1.3, basically editorial rearrangement of text to take
>>>>account of the fact that the ingress node will always perform
>>>>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
>>>>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
>>>which MIB?
>>
>>[PTT] DiffServ MIB [RFC3289], referenced in the document.
>ok, now I see the reference was some sentences before
>
>>>
>>>>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.
>>>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).
>>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