Subject: [Tsvwg] Comments on draft-ietf-tsvwg-ecn-mpls-00

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 May 2007 14:31:49 +0200

Hi,

Here are some comments. Most are related to how PCN is being discussed 
within this draft.

1. Section 1.3:
   "Nonetheless, we do specify how the egress node of an MPLS domain
    should copy congestion notification from the MPLS shim into the
    underlying IP header if the ECN is to be carried onward towards the
    IP receiver."

Is really "underlying" the right word? Isn't "encapsulated" or something 
  that clearer indicates the IP packet that is carried over the MPLS 
network? But this seems to be a result of that I and the author has 
different views on what is up and down in the stack.

2. Section 2:
   "We recommend that explicit congestion notification in MPLS should use
    codepoints instead of bits in the EXP field.  Since not every PHB
    will need an associated ECN codepoint and in some applications a
    given PHB might need two ECN codepoints (see, for
    example,[I-D.briscoe-tsvwg-cl-architecture]) it would be wasteful to
    assign a dedicated bit for ECN."

I agree with the conclusion, but I am a bit worried by the usage of PCN 
as motivation. It would be better if there exist other already finished 
work that motivates it. Because the fact is that we don't yet know 
exactly how PCN will look like.

3. Section 2: Using PCN as the primary motivator for needing two states. 
To me it seems that the approach taken can be motivated without PCN, 
just using regular ECN. I would recommend that we tone down PCN for the 
moment. It is fine to consider its basic requirements. But as PCN isn't 
finished and we not yet know for certain what is needed to support PCN 
in MPLS. Lets not write that document yet. The goal is to handle ECN for 
MPLS.

4. Section 4.8:

I am not comfortable with having this section until the PCN WG has 
produced stable WG documents defining how PCN actually works. My only 
interpretation of this section is that it is a normative reference to 
PCN. Thus ECN for MPLS can't be published until the necessary PCN 
specifications are published. I would propose to remove this section for 
now to allow this document to be published now rather then later.

But it is good to know that you likely have something that will work 
with PCN, even if it will eat a lot of EXP codepoints.

5. Section 11. Inclusion of re-ecn discussion in security consideration. 
I can't understand what applicability this paragraph has to ECN marking 
as currently defined within MPLS.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 May 2007 15:54:05 +0100

Magnus,

At 13:31 14/05/2007, Magnus Westerlund wrote:
>Is really "underlying" the right word? Isn't "encapsulated" or 
>something  that clearer indicates the IP packet that is carried over the 
>MPLS network? But this seems to be a result of that I and the author has 

I have no problem with changing to:
"...copy congestion notification from the MPLS shim into the encapsulated 
IP header..."

>I agree with the conclusion, but I am a bit worried by the usage of PCN as 
>motivation. It would be better if there exist other already finished work 
>that motivates it. Because the fact is that we don't yet know exactly how 
>PCN will look like.
>
>To me it seems that the approach taken can be motivated without PCN, just 
>using regular ECN. I would recommend that we tone down PCN for the moment. 
>It is fine to consider its basic requirements. But as PCN isn't finished 
>and we not yet know for certain what is needed to support PCN in MPLS. 
>Lets not write that document yet. The goal is to handle ECN for MPLS.

There is no other finished work to motivate multiple codepoints per PHB. 
But the main motivation for using codepoints not bits is for the cases 
where a PHB needs n associated codepoints, where n=0. Cases where n>1 are 
an extra luxury the approach allows for free.

So I have no problem removing the PCN example at this point (we could 
instead refer forward to section 8.4, where it is clearer that PCN is a 
possible example of n>1 codepoints).

>interpretation of this section is that it is a normative reference to PCN. 
>Thus ECN for MPLS can't be published until the necessary PCN 
>But it is good to know that you likely have something that will work with 
>PCN, even if it will eat a lot of EXP codepoints.

Yes, I think we should move all of 4.8 to an appendix.

I think section 8.4 on PCN is OK as it is (with suitably updated refs to 
the diffserv class aggr stuff), because it is clear that it is an example, 
and it explains what assumptions it is making about PCN.

So, I think 4.8 could be moved to an appendix, then 8.4 could stay where it 
is, and refer to the appendix as a detailed description of the marking 
functions of an example like PCN.

>5. Section 11. Inclusion of re-ecn discussion in security consideration. I 
>can't understand what applicability this paragraph has to ECN marking as 
>currently defined within MPLS.

It's just saying that putting ECN in MPLS as described is independent of 
the re-ECN proposal, which still works, for the same reason the ECN nonce 
still works, because neither depend on any change to the way routers do 
marking.

Are you saying this para is unclear or unnecessary?

Bob

>IETF Transport Area Director & TSVWG Chair

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 May 2007 17:11:40 +0200

Bob Briscoe skrev:
>> something  that clearer indicates the IP packet that is carried over 
>> the MPLS network? But this seems to be a result of that I and the 
>> author has different views on what is up and down in the stack.
> 
> "...copy congestion notification from the MPLS shim into the 
> encapsulated IP header..."
> 

Great.

>> I agree with the conclusion, but I am a bit worried by the usage of 
>> PCN as motivation. It would be better if there exist other already 
>> finished work that motivates it. Because the fact is that we don't yet 
>> know exactly how PCN will look like.
>>
>> 3. Section 2: Using PCN as the primary motivator for needing two 
>> states. To me it seems that the approach taken can be motivated 
>> without PCN, just using regular ECN. I would recommend that we tone 
>> down PCN for the moment. It is fine to consider its basic 
>> requirements. But as PCN isn't finished and we not yet know for 
>> certain what is needed to support PCN in MPLS. Lets not write that 
>> document yet. The goal is to handle ECN for MPLS.
> 
> where a PHB needs n associated codepoints, where n=0. Cases where n>1 
> are an extra luxury the approach allows for free.

Yes, I got that impression that it was well motivated without PCN.

> possible example of n>1 codepoints).

Sounds like a workable solution.

>> specifications are published. I would propose to remove this section 
>> for now to allow this document to be published now rather then later.
>>

Okay, that will work as long as you are very clear that this is only a 
suggestion on how this could be implemented and not normative 
specification.

> the diffserv class aggr stuff), because it is clear that it is an 
> example, and it explains what assumptions it is making about PCN.

Okay.

> 
> So, I think 4.8 could be moved to an appendix, then 8.4 could stay where 
> it is, and refer to the appendix as a detailed description of the 
> marking functions of an example like PCN.

Okay.

> 
>> 5. Section 11. Inclusion of re-ecn discussion in security 
>> consideration. I can't understand what applicability this paragraph 
>> has to ECN marking as currently defined within MPLS.
> 
> the re-ECN proposal, which still works, for the same reason the ECN 
> nonce still works, because neither depend on any change to the way 
> routers do marking.
> 

Unnecessary, as I don't see how it applies to any defined or deployed 
technology.

Cheers

Magnus Westerlund