Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-04 as Proposed Standard

From: <[email-masked]>
Date: Tue, 1 Mar 2011 10:01:22 +0000

Looks good, only minor comments:-

P1 - correct intended status
Add sentence at end of abstract: "It assumes any tunnels in the PCN-domain comply with [RFC6040]."

P3 - add a short para 4 that explains the extension is Stds track (despite 5696 calling it an experimental codepoint! - ie WG agreed this was only encoding, beyond the baseline, to go forward with etc

P3 last sentence - there is a ref to Appendix A which doesn't exist.

P6, end of para under fig 1, suggest add "(<...> indicates the RFC3168 codepoint name.)"
P6, in the bullets, change "(not-ECT)" to "<not-ECT>" etc.
[this is for consistency with Fig 2, and i think is clearer]

P7 para 1, I'de delete mention of CE, ECT(1) & ECT(0) and replace with (11), (01) & (10)
Ie the main names for the codepoints are the PCN names for them, in the context of the doc. The ECT names are just for interest and only need to be mentioned once. 
Before "is more severe" you could add ", which in turn "

P8, line 2 - at the end of the definition of Threshold-marked, maybe add "and not by an excess-traffic-marker"

P10, S9 - "PCN region" -> "PCN-domain". Can safely delete "have been updated to"

P11, rfc5129 i think should be an Informative ref [not Normative] - or could be deleted.

Thanks
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steven Blake
Sent: 28 February 2011 03:49
To: [email-masked]
Subject: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-04 as Proposed Standard

There were two ayes and no nays for re-categorizing 
http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-04
as a Proposed Standard, so we will proceed along that path.

This begins a two-week WGLC for this draft, to end Monday March 14.
Please send comments to the list.

Regards,

// Steve

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 1 Mar 2011 10:39:50 -0000

Hi Phil,

Thanks for the comments. One question for the WG (or even IESG) - since this
will now be creating a standards track use for the EXP codepoint, does that
make this document an update to RFC5696? I can't remember the rules on that
sort of thing.

Toby 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 01 March 2011 10:01
> To: [email-masked]; [email-masked]
> Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-04 as
> Proposed Standard
> 
> P3 - add a short para 4 that explains the extension is Stds track
> (despite 5696 calling it an experimental codepoint! - ie WG agreed this
> was only encoding, beyond the baseline, to go forward with etc
> 
> Ie the main names for the codepoints are the PCN names for them, in the
> context of the doc. The ECT names are just for interest and only need
> to be mentioned once.
> P8, line 2 - at the end of the definition of Threshold-marked, maybe
> add "and not by an excess-traffic-marker"
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 14 Mar 2011 12:20:17 +0100

Hi Steve, Hi all

I have checked the draft-ietf-pcn-3-in-1-encoding-04. 

In my opinion the draft is good enough to proceed on the AD review phase.
However, as already Bob recommended it might be good to
add a description in the pcn-3-in-1-encoding draft to show how RFC6040 could
be used to alos support e2e ECN!

Best regards,
Georgios

> Sent: maandag 28 februari 2011 4:49
> To: [email-masked]
> Subject: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-04 as 
> ProposedStandard
>

---

From: Steven Blake <[email-masked]>
Date: Sun, 20 Mar 2011 23:53:21 -0400

> Please send comments to the list.

The WGLC has run on past the deadline.  The discussion has been good.
Could someone summarize the conclusion of the "Effect on RFC 6040 on
PCN" thread, *as it applies to this draft*?  I would like to wrap this
up in a few days.

Thanks,

// Steve

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 21 Mar 2011 09:09:44 -0000

Bob is probably best placed to comment on this, as he is the main author of
both documents. 

I am reasonably happy with Michael's suggestion of a short addition to the
draft about tunnelling, although I would phrase it a little differently.

Toby

> Steven Blake
> Sent: 21 March 2011 03:53
> To: [email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Mar 2011 14:59:21 +0000

Steve,

Agree with Toby & Michael.

Ie, we need discussion somewhere about:
1) how to preserve e2e ECN (whether with baseline or 3-in-1 encoding)

Rather than a whole new draft/RFC just for that, best thing is to add 
a section to pcn-3-in-1-encoding on supporting e2e ECN, as Michael suggests.

However, I'm not so convinced we need that much more text on:
2) constraints for tunnels within a PCN-domain using 3-in-1

Michael says the 6040 constraint only first appears in the 
conclusions, but it's also there under applicability (section 3.3) 
and 6040 is mentioned in other places. I have no problem beefing up 
the text we've already got on PCN interaction with tunnels, but I 
can't see that any completely new discussion on this needs to be added.

I do agree that we should say that RFC 6040 Normal Mode is sufficient 
for a tunnel ingress in a PCN domain.

Cheers

Bob

> > PCN" thread, *as it applies to this draft*?  I would like to wrap this

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Michael Menth <[email-masked]>
Date: Mon, 21 Mar 2011 18:02:18 +0100

Hi Bob,

Am 21.03.2011 15:59, schrieb Bob Briscoe:
> conclusions, but it's also there under applicability (section 3.3) and 
> 6040 is mentioned in other places. I have no problem beefing up the 
> text we've already got on PCN interaction with tunnels, but I can't 
> see that any completely new discussion on this needs to be added.
The intent of Section 3.3 is to describe the applicability of 3-in-1 
encoding, but this passage does not give guidelines on how tunnels 
should be set up within a PCN domain. I don't think that the short 
paragraph I proposed starts a new discussion or significantly extends 
the document (see attached email). It just says how RFC6040 can be 
applied for correctly setting up tunnels within PCN domains. That 
information is missing. I think it is useful to spell that out somewhere 
explicitly. People who have not followed and understood the tricky 
discussions will benefit from that information.

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: Handling of ECN and intra-PCN-domain tunnels in 3-in-1-encoding
From: Michael Menth <[email-masked]>
To: [email-masked]
Cc: Bob Briscoe <[email-masked]>, Tom Taylor <[email-masked]>, Toby Moncaster <[email-masked]>
Date: Mon, 14 Mar 2011 14:59:40 +0100

Hi all,

Section 3.2 of 3-in-1-encoding
http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-04#section-3.2
explains why 3-in-1-encoding looks as it does and Section 3.3 makes 
clear that it reqires RFC6040.
Section 6 of 3-in-1-encoding
http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-04#section-6
explains only how compatibility with baseline encoding is achieved.

However, we did not explicitly say:
1) How ECN traffic should be handled across PCN domains
2) How tunnels are set up within PCN domains (only shortly mentioned in 
the conclusion)

I think that an addition along the following lines makes this clearer 
and reflects the email thread we just had, at least I hope so.

1) Handling of ECN traffic across PCN domains

There are currently two options for handling ECN traffic across PCN domains.
a) The PCN ingress node resets the ECN field to NM.
    The PCN egress node resets the ECN field to not-ECT.
    Thereby, ECN functionality is disabled.
b) A tunnel is set up across the PCN domain from the PCN ingress node 
towards the PCN egress node according to RFC6040.
    That means, the PCN ingress node encapsulates packets towards the 
PCN egress node.
    Then, PCN ingress and egress node perform the operations listed at a)
    Then, the PCN egress node decapsulates packets according to RFC6040.
    Thereby, the original ECN codepoints are restored in the packet headers.

2) Setting up Tunnels within PCN domains

    A tunnel may be set up from node A to node B within a PCN domain 
according to the normal mode of RFC6040.
    That means, node A encapsulates a packet and copies the ECN field of 
the inner header to the outer header.
    Then, node B decapsulates the packet according to the rules in RFC6040.

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Mar 2011 21:42:45 +0000

Michael,

I'm just saying less is more. All we need to say is that Normal Mode 
of RFC6040 was designed to be sufficient for all tunnels, including 
tunnels within a PCN domain.

Bob

At 17:02 21/03/2011, Michael Menth wrote:
>>Rather than a whole new draft/RFC just for that, best thing is to 
>>add a section to pcn-3-in-1-encoding on supporting e2e ECN, as 
>>Michael suggests.
>>
>paragraph I proposed starts a new discussion or significantly 
>extends the document (see attached email). It just says how RFC6040 
>can be applied for correctly setting up tunnels within PCN domains. 
>That information is missing. I think it is useful to spell that out 
>somewhere explicitly. People who have not followed and understood 
>the tricky discussions will benefit from that information.
>
>Best wishes,
>
>     Michael
>
>
>>
>>I do agree that we should say that RFC 6040 Normal Mode is 
>>sufficient for a tunnel ingress in a PCN domain.
>>
>>Cheers
>>
>>
>>Bob
>>
>>
>Message-ID: <[email-masked]>
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; 
>rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
>MIME-Version: 1.0
>To: [email-masked]
>CC: Bob Briscoe <[email-masked]>, Tom Taylor <[email-masked]>,
>  Toby Moncaster <[email-masked]>
>Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>Content-Transfer-Encoding: 7bit

---

From: Steven Blake <[email-masked]>
Date: Wed, 30 Mar 2011 21:57:18 -0400

> tunnels within a PCN domain.

I am not seeing rough consensus to advance this draft as is (but I
appreciate the extensive discussion).

Editors: please discuss Friday and spin this draft again, and then we
will run an abbreviated WGLC.

Regards,

// Steve

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 08:28:34 +0100

also, it would be good on friday to discuss / get AD guidance on the issue about its relationship with Baseline encoding

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Steven Blake [[email-masked]]
Sent: 31 March 2011 02:57
To: pcn
Subject: [PCN] Conclusion: WGLC for draft-ietf-pcn-3-in-1-encoding-04 as Proposed Standard

Regards,

// Steve