Subject: [PCN] I-D Action: draft-ietf-pcn-sm-edge-behaviour-11.txt

From: [email-masked]
Date: Wed, 04 Apr 2012 17:31:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF.

	Title           : PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation
	Author(s)       : Anna Charny
                          Georgios Karagiannis
                          Michael Menth
                          Tom Taylor
	Filename        : draft-ietf-pcn-sm-edge-behaviour-11.txt
	Pages           : 32
	Date            : 2012-04-04

   Pre-congestion notification (PCN) is a means for protecting the
   quality of service for inelastic traffic admitted to a Diffserv
   domain.  The overall PCN architecture is described in RFC 5559.  This
   memo is one of a series describing possible boundary node behaviours
   for a PCN-domain.  The behaviour described here is that for a form of
   measurement-based load control using two PCN marking states, not-
   marked, and excess-traffic-marked.  This behaviour is known
   informally as the Single Marking (SM) PCN-boundary-node behaviour.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-11.txt

---

From: Tom Taylor <[email-masked]>
Date: Wed, 04 Apr 2012 21:31:32 -0400

Changes listed below were as agreed at the meeting (use 3-in-1 rather 
than RFC5696, recognize possible use of MPLS, correct error). I found a 
few additional points that also needed fixing, as noted below.

Section 1, description of experiment, bullets
---------------------------------------------
Changed "CL" to "SM" (cut-and-paste error).

Section 1.1, codepoint terminology
----------------------------------
Changed reference and terminology to 3-in-1.

Section 2 second bullet
-----------------------

OLD

  o excess-traffic-marking of PCN-packets uses the PCN-Marked (PM) 
codepoint defined in [RFC5696];

NEW

  o for IP transport, excess-traffic-marking of PCN-packets uses the 
excess-traffic-marked (ETM) codepoint defined in [ID.pcn-3-in-1]; for 
MPLS transport, an equivalent marking is used as discussed in 
[ID.pcn-3-in-1] Appendix C;	

Section 2 last bullet
---------------------

OLD

  o the set of valid codepoint transitions is as shown in Section 4.2 
of [RFC5696].		

NEW

  o the set of valid codepoint transitions is as shown in Sections 5.2.1 
and 5.2.3.1 of [ID.pcn-3-in-1].	

Section 3.2.1, definition of ETM-rate
-------------------------------------
Changed "PM codepoint" to "ETM codepoint".

Section 3.3, second sentence
----------------------------
Restored the "Decision Points MUST implement both" as agreed at the meeting.

Section 3.3.2, end
------------------
Added the following to tie things together:

    The Decision Point SHOULD log each round of termination as described	
    in Section 5.2.1.2.
	
Section 3.3.3, action on missing response from ingress node
-----------------------------------------------------------
(Identified error) Deleted the workaround procedure, which was suitable 
only for CL. Text now reads:

[SM-specific] If the second request to the PCN-ingress-node also fails, 
the Decision Point SHOULD notify management. The log format defined in 
Section 5.2.1.1 is also suitable for this case.

Section 3.5, action on expiry of t_meas
---------------------------------------
Deleted CL-specific text (cut-and-paste error).

Section 4.2.1
-------------
Replaced first two paragraphs with reference to relevant section of 3-in-1.

Section 4.2.2
-------------
Changed reference from RFC5696 to 3-in-1.

Section 4.6
-----------
Changed "MAY" to "may" for example uses.

Section 4.7
-----------
Replaced existing text.

OLD

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.

NEW

    The PCN SM per-domain behaviour could theoretically interfere with
    the use of end-to-end ECN due to reuse of ECN bits for PCN marking.
    Section 5.1 of [ID.pcn-3-in-1] describes the actions that can be
    taken to protect ECN signalling.  Appendix B of that document
    provides further discussion of how ECN and PCN can co-exist.

Section 5.1.1 second bullet
---------------------------
Changed reference to 3-in-1 Appendix A.

Section 5.1.2, second paragraph, last sentence
----------------------------------------------

OLD

Since all PCN packets will be tunneled, the PCN-ingress-node also needs 
to know the address of the peer PCN-egress-node associated with each filter.

NEW

The PCN-ingress-node also needs to know the address of the next-hop 
PCN-node associated with each filter.

*Comment*: I think I should have added: "If tunneling is used, the 
next-hop PCN-node will be the peer PCN-egress-node."

*Further comment*: how should this read for MPLS?

Section 5.1.2, fourth paragraph, saecond sentence
-------------------------------------------------
Added "If tunneling is used ...", so the sentence now reads:

If tunneling is used, these filters are
    constructed on the basis of the identifier of the tunnel from which
    the incoming packet has emerged (e.g. the source address in the outer
    header if IP encapsulation is used).

Section 5.1.3, first paragraph, last sentence
---------------------------------------------
Revised to drop CL-specific stuff and correct misleading text. New text 
reads:

    "Finally, a new object may need to be defined at the PCN-
    interior-nodes to represent the packet-size-independent excess-
    traffic-marking metering algorithm."

Section 5.2.1.1, second paragraph
---------------------------------
Added "PCN-ingress-node or ..." to make it clear the log could be used 
for missing reports at both ingress and egress.

Section 5.2.1.2, description of "TermRate" parameter
----------------------------------------------------
Units changed from millions of octets per second to thousands of octets 
per second -- seemed more reasonable on reflection.

Normative References
--------------------
Deleted RFC5696, added 3-in-1.

Authors
-------
Restored Joy Zhang's missing E-mail address.

---

From: <[email-masked]>
Date: Thu, 5 Apr 2012 08:58:58 +0200

Hi Tom,

thanks. You've requested comments on

#######

OLD

NEW

#########

My take is that the tunnel terminates at the PCN-egress-node or at least
at a node having this functionality. So the next hop as seen from the inner
(tunneled) packet is the PCN-egress-node.

The next-hop node following the PCN ingress node should have SM PCN marking
capability, no matter whether it is an IP node or an MPLS node. The next hop
as seen from the outer (tunnel header) packet is a PCN node.

Regards,

Ruediger

Please note that I will be off until 16. April and will not respond to mails before that day.

---

From: Michael Menth <[email-masked]>
Date: Thu, 05 Apr 2012 09:11:19 +0200

Hi Ruediger,

was this the issue with pen-ultimate hop popping? If so, this problem 
should be explicitly addressed, otherwise it will be just lost as I am 
already now not sure what the background of this text is.

Best wishes,

     Michael

Am 05.04.2012 08:58, schrieb [email-masked]:
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

-- 
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: <[email-masked]>
Date: Thu, 5 Apr 2012 10:03:56 +0200

Hi Michael,

if public IP traffic is tranported, the pen ultimate hop removes the
last MPLS label. Then there's an IP header below and it must receive the
correct CE codepoint. Tom's issue is something different.

I didn't check whether there are IP-in-IP tunnels which would be
regarded as public instead of VPN. I don't want to invest too much
time, as I prefer an approach working with ECMP and public IP, ie.
no tunnels.

Regards,

Ruediger

-----Original Message-----
From: Michael Menth [mailto:[email-masked]]
Sent: Thursday, April 05, 2012 9:11 AM
To: Geib, Rüdiger
Cc: [email-masked]; [email-masked]
Subject: Re: [PCN] I-D Action: draft-ietf-pcn-sm-edge-behaviour-11.txt

Hi Ruediger,

Best wishes,

     Michael

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Apr 2012 08:46:15 -0400

Thanks in return.

You may have noticed that I made a couple of changes that had ther 
effect of covering cases where tunneling is not used. I did that because 
we don't have language in section 5.2.1 mandating tunneling, just 
pointing out its logical necessity in most circumstances. A corner case 
could exist where it's not required.

If I keep to the spirit of that and also take account of your response, 
the best thing to do is to restore the original sentence but replace 
"Since" with "If".

On 05/04/2012 2:58 AM, [email-masked] wrote:
> .