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

[Bob Briscoe <[e-mail]>]

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.
>
>On 22/03/2012 6:57 PM, Bob Briscoe wrote:
>>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
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design