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

[Tom Taylor <[e-mail]>]

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
>