Subject: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Nov 2006 02:48:11 -0800

Hi,
(BCC MPLS for information)

Based on feedback from the TSVWG session in San Diego we think there is 
consensus on adopting draft-davie-ecn-mpls as a TSVWG work item. We are 
hereby confirming this consensus on the list. If you have an opinion 
please state it.

Cheers

Magnus Westerlund
TSVWG chair

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 14 Nov 2006 12:06:30 +0100

Hello,
I support draft-davie-ecn-mpls being adopted as WG document.
Cheers
Francois

On 14 Nov 2006, at 11:48, Magnus Westerlund wrote:

> Based on feedback from the TSVWG session in San Diego we think  
> there is consensus on adopting draft-davie-ecn-mpls as a TSVWG work  
> item. We are hereby confirming this consensus on the list. If you  
> have an opinion please state it.
>
> Cheers
>
> Magnus Westerlund
> TSVWG chair
>

---

From: [email-masked]
Date: Wed, 15 Nov 2006 00:07:33 +0100

hi -

1. CN marking in the EXP bits of the MPLS header falls imho under the 
MPLS change process that states for an optional problem statement and
a mandatory prior requirements statement I-D to commit for any specific 
change or extension to MPLS

see section 2.1.1 and 4.2 of
 
<http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-06.txt>

2. on one side there is a PCN BoF during previous meeting on the other
the document uses PCN as motivation for copying the CE state into outer 
header at ingress - if found this rather circular as reasoning where is 
the real "problem statement" outside PCN scope for such operation ?

thanks,
- d.

Magnus Westerlund <[email-masked]>
14/11/2006 11:48
 
        To:     tsvwg <[email-masked]>
        cc: 
        Subject:        [mpls] Making draft-davie-ecn-mpls a TSVWG item

Hi,

Cheers

Magnus Westerlund
TSVWG chair

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Wed, 15 Nov 2006 10:41:27 -0000

I support making this a wg doc

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: 14 November 2006 10:48
To: tsvwg
Subject: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item

Hi,

Cheers

Magnus Westerlund
TSVWG chair

---

From: Bruce Davie <[email-masked]>
Date: Wed, 15 Nov 2006 07:55:20 -0500

> <http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls- 

I'll let the ADs and WG chairs argue about the process issue  you've  

> the real "problem statement" outside PCN scope for such operation ?

I wonder if perhaps you have not read the latest (-01) version of  
draft-davie-ecn-mpls

You will notice that the abstract does not mention PCN, and that the  
list of changes from the last draft includes this statement:

    o  Pre-congestion notification (PCN) marking is now described in a
       way that does not require normative references to PCN
       specifications.  PCN discussion now serves only to illustrate how
       the ECN marking concepts can be extended to cover more complex
       scenarios, with PCN being an example.

The motivation for this work is to prevent ECN from being broken when  
traversing an MPLS network. That seems sufficient motivation for the  
draft whether or not PCN becomes a problem that the IETF wants to  
work on.

Bruce

> there is

---

From: [email-masked]
Date: Wed, 15 Nov 2006 15:20:16 +0100

Bruce Davie <[email-masked]>
15/11/2006 13:55
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     Magnus Westerlund <[email-masked]>, tsvwg 
<[email-masked]>
        Subject:        Re: [Tsvwg] Re: [mpls] Making draft-davie-ecn-mpls 
a TSVWG item

[dp] i read that version - my remark refers to section 7. in that 
section it seems that the inner->outer CE is driven by PCN needs (also
part of the discussion slides)

[dp] the same section 7 mentions

"[RFC3168] does not give any reasons against conveying CE information
 from the inner header to the outer in the "full functionality" mode."

nor the other way around - which leaves the point open for ECN itself
-> the issue i am raising is that in absence of evidence current the 
processing should be left per RFC3168 and not inline with the expected
PCN needs (even if it does not affect the former)

-d.