Subject: [PCN] PCN encoding for MPLS shim headers

From: Michael Menth <[email-masked]>
Date: Fri, 10 Jun 2011 18:44:06 +0200

Hi Toby,

I just realized that the introduction of the 3-in-1 doc says "For 
example, the MPLS encoding is defined in [RFC5129 
<http://tools.ietf.org/html/rfc5129>] and Appendix A 
<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-05#appendix-A> of 
that document provides an informative example for a mapping between the 
encodings in IP and in MPLS." but the Appendix does not provide such 
information.

We agreed about a year ago to provide such information in an appendix of 
the 3-in-1 encoding doc as RFC5129 is not explicit enough about how PCN 
may be encoded in MPLS shim headers. Somehow this information was lost. 
I digged in my emails. You find the lost appendix in the Word file 
attachment in the attached private email. Can you please add that before 
it is lost again?

Best wishes,

     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://www-kn.informatik.uni-tuebingen.de

Subject: Fwd: Re: deferring PCN stuff to next Monday - week off
From: Bob Briscoe <[email-masked]>
To: Michael Menth <[email-masked]>
Date: Mon, 19 Jul 2010 22:13:43 +0100

Michael,

I just noticed your final comment about missing the MPLS appendix by accident.

I've attached your Word doc, but with some 
additional edits within that final appendix, to 
explain better and to warn that it's non-normative etc.

THere are no other edits outside that appendix.

HTH

BOb

>Date: Mon, 19 Jul 2010 21:41:52 +0100
>To: [email-masked]
>From: Bob Briscoe <[email-masked]>
>Subject: Re: deferring PCN stuff to next Monday - week off
>Cc: Toby Moncaster <[email-masked]>, Michael 
>Höfli ng <[email-masked]>
>Bcc: ƒ\In 2009
>
>Michael,
>
>Thanks for confirmation of most of the changes 
>(snipped). And for the XML. Just one outstanding issue below...
>
>At 20:28 14/07/2010, Michael Menth wrote:
>>The only disagreement we still have is that you 
>>say ETM must be more severe than ThM while I do 
>>not see any strong reason to have that 
>>constraint which possibly could preclude future 
>>use of pcn-marking for whatever.
>>
>>You find my comments in the attached doc file.
>
>In your Word comment responding to my suggested 
>change concerning severity ordering, you said:
>
>>That was my “favourite debate” some years ago. 
>>The pcn-admissible-rate must be smaller than 
>>the pcn-supportable-rate, but anything about 
>>the marking stuff depends on the edge behaviour.
>>
>>Just saying that the informational RFC says 
>>that excess-traffic-marking is more severe than 
>>threshold-marking is from my perspective not 
>>sufficient. Are there good reasons to have that 
>>order? I do not see any reasonable edge 
>>behaviour that would use  the two marking 
>>schemes the other way around, but I do not see 
>>any reasons either why we need this constraint 
>>that possibly might prohibit future use of pcn-marking for different apps.
>
>I thought about this before writing. If one rate 
>is higher than another, then the encoded marking 
>of that higher rate has to rank higher than the 
>marking of the lower rate, for cases with 
>multiple bottlenecks. Otherwise the marking algo 
>doesn't know whether it is allowed to overwrite 
>marking Th with marking E and whether it is not 
>allowed to overwrite marking E with marking Th.
>
>Or am I missing some subtlety in your point?
>
>
>Bob
>
>
>>Best wishes,
>>
>>    Michael
>>
>>>
>>>
>>>
>>>Bob
>>>
>>>At 23:15 12/07/2010, Bob Briscoe wrote:
>>>>Michael,
>>>>
>>>>SOrry I'm back to this late (just been over 
>>>>to my fathers for his 80th birthday) - I see 
>>>>you've posted the draft, so it's fine. Thank 
>>>>you v much and thank you to Michael Höfling also.
>>>>
>>>>I've answered your questions anyway below...
>>>>
>>>>At 17:12 12/07/2010, Michael Menth wrote:
>>>>>Hi Bob,
>>>>>
>>>>>I had a hard time to understand what you wrote in the
>>>>>compatibility section 6.1. I think that I have understood it now
>>>>>and reformulated it so that I could understand it faster. Is that
>>>>>wording ok with you?
>>>>>
>>>>>"The term "compatibility" is meant in the following sense. It is
>>>>>possible to operate nodes with baseline encoding [5696] and 3-in-1
>>>>>encoding in the same PCN domain. The nodes with baseline encoding
>>>>>MUST perform excess-traffic-marking because the 11 codepoint of
>>>>>3-in-1 encoding also means excess-traffic-marked.
>>>>>PCN-boundary-nodes of such domains are required to interpret the
>>>>>full 3-in-1 encoding and not just baseline encoding, otherwise
>>>>>they cannot interpret the 01 codepoint.
>>>>>
>>>>>Using nodes that perform only excess-traffic-marking may make
>>>>>sense in networks using the CL edge behavior
>>>>>[I-D.ietf-pcn-cl-edge-behaviour]. Such nodes are able to notify
>>>>>the egress only about severe pre-congestion when traffic needs to
>>>>>be terminated. This seems reasonable for locations that are not
>>>>>expected to see any pre-congestion, but excess-traffic-marking
>>>>>gives them a means to terminate traffic if unexpected overload
>>>>>still occurs."
>>>>
>>>>That's correct.
>>>>
>>>>
>>>>
>>>>>Where exactly is the appropriate location in the draft for this
>>>>>text?
>>>>>
>>>>>"Note:  IANA Considerations
>>>>>
>>>>>   This memo includes no request to IANA.
>>>>>
>>>>>   Note to RFC Editor: this section may be removed on publication as an
>>>>>   RFC."
>>>>>
>>>>>Shouldn't that be an extra section? I don't understand what it has
>>>>>to do in the compatibility section.
>>>>
>>>>Sorry - rather than incrementing all the 
>>>>section numbers to allow for the section I 
>>>>had just inserted, I merely turned this into 
>>>>a note. It was meant to be another section (but it will be deleted anyway).
>>>>
>>>>Thank you again.
>>>>
>>>>
>>>>Bob
>>>>
>>>>
>>>>>Regards,
>>>>>
>>>>>    Michael
>>>>>
>>>>>Bob Briscoe schrieb:
>>>>>>Michael,
>>>>>>
>>>>>>[Toby, pls supply Michael with new contact 
>>>>>>details. I have listed your affiliation as 
>>>>>>'independent' - you may choose some other wording.]
>>>>>>
>>>>>>Attached are my comments.
>>>>>>
>>>>>>They are all largely cosmetic, or reducing ambiguity.
>>>>>>
>>>>>>I have added section 6 on backward 
>>>>>>compatibility. You may choose to edit it 
>>>>>>yourself. I have shifted your Appx A into it as Section 6.3.
>>>>>>
>>>>>>
>>>>>>[Sorry 90mins late - I had to go to the 
>>>>>>doctors this morning on top of everything else.]
>>>>>>
>>>>>>
>>>>>>Bob
>>>>>>
>>>>>>At 03:03 12/07/2010, Bob Briscoe wrote:
>>>>>>>Michael,
>>>>>>>
>>>>>>>At 10:57 05/07/2010, Michael Menth wrote:
>>>>>>>>Hi Bob,
>>>>>>>>
>>>>>>>>ok. I can wait until next Monday with 
>>>>>>>>this draft. But it's important to have 
>>>>>>>>your feedback by 11am so that we have a 
>>>>>>>>fair chance to integrate your comments, 
>>>>>>>>update the xml, and submit it by the evening.
>>>>>>>
>>>>>>>OK, I will try.
>>>>>>>I have just returned from the C16 and 
>>>>>>>printed it out to read and comment in the morning.
>>>>>>>
>>>>>>>
>>>>>>>Bob
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Best wishes,
>>>>>>>>
>>>>>>>>    Michael
>>>>>>>>
>>>>>>>>Bob Briscoe schrieb:
>>>>>>>>>Toby, Michael,
>>>>>>>>>
>>>>>>>>>Not ideal, but I will return to the grid 
>>>>>>>>>next Sunday/Monday, leaving one day 
>>>>>>>>>before the IETF deadline. Ran out of time this weekend. Sorry.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Bob
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>________________________________________________________________
>>>>>>>>>Bob Briscoe,                                BT Innovate & Design
>>>>>>>>
>>>>>>>>--
>>>>>>>>PD Dr. habil. Michael Menth, Assistant Professor
>>>>>>>>University of Wuerzburg, Institute of Computer Science
>>>>>>>>Am Hubland, D-97074 Wuerzburg, Germany, room B206
>>>>>>>>phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
>>>>>>>>mailto:[email-masked]
>>>>>>>>http://www3.informatik.uni-wuerzburg.de/research/ngn
>>>>>>>
>>>>>>>________________________________________________________________
>>>>>>>Bob Briscoe,                                BT Innovate & Design
>>>>>>
>>>>>>________________________________________________________________
>>>>>>Bob Briscoe,                                BT Innovate & Design
>>>>>
>>>>>--
>>>>>PD Dr. habil. Michael Menth, Assistant Professor
>>>>>University of Wuerzburg, Institute of Computer Science
>>>>>Am Hubland, D-97074 Wuerzburg, Germany, room B206
>>>>>phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
>>>>>mailto:[email-masked]
>>>>>http://www3.informatik.uni-wuerzburg.de/research/ngn
>>>>
>>>>________________________________________________________________
>>>>Bob Briscoe,                                BT Innovate & Design
>>>
>>>________________________________________________________________
>>>Bob Briscoe,                                BT Innovate & Design
>>
>>--
>>PD Dr. habil. Michael Menth, Assistant Professor
>>University of Wuerzburg, Institute of Computer Science
>>Am Hubland, D-97074 Wuerzburg, Germany, room B206
>>phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
>>mailto:[email-masked]
>>http://www3.informatik.uni-wuerzburg.de/research/ngn
>>
>>
>>
>>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: <[email-masked]>
Date: Tue, 14 Jun 2011 11:57:11 +0200

Hello Toby,

thanks to Michael for pointing out the gap and the solution in the state that has been reached. I agree that the text worked out by Michael and Bob should be added as informative appendix.

Regards,

Ruediger

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Friday, June 10, 2011 6:44 PM
To: Toby Moncaster
Cc: [email-masked]
Subject: [PCN] PCN encoding for MPLS shim headers

Hi Toby,

I just realized that the introduction of the 3-in-1 doc says "For example, the MPLS encoding is defined in [RFC5129<http://tools.ietf.org/html/rfc5129>] and Appendix A<http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-05#appendix-A> of that document provides an informative example for a mapping between the encodings in IP and in MPLS." but the Appendix does not provide such information.

We agreed about a year ago to provide such information in an appendix of the 3-in-1 encoding doc as RFC5129 is not explicit enough about how PCN may be encoded in MPLS shim headers. Somehow this information was lost. I digged in my emails. You find the lost appendix in the Word file attachment in the attached private email. Can you please add that before it is lost again?

Best wishes,

    Michael