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

[[e-mail]]

lars - 

i am more generally questioning cost/perf. gain & value for 3
major reasons (they would deserve imho further discussion - or 
at least further proof of evidence)

o) if it is to come up with a forwarding paradigm that becomes 
equivalent to IP probably we should then start questioning the 
need for MPLS itself (in part. in the present case focusing on
intra-domain operations where i always thought that data-traffic
and resource-oriented perf. objectives were taken into account
for edge-to-edge MPLS path provisioning)

o) MPLS paradigm assumed "intelligence@edges" we progressively 
enter into a mode where intermediate LSRs will become (see end 
of section 3) progressively require/result again more selective 
processing of traffic

o) initial MPLS-ECN based its reasoning on expectations from
experience - quoting:

"We believe the benefits from ECN of better overall performance
for a wide range of applications because of reduced packet loss
(especially those using non-TCP transports) and reduced queueing
delay is sufficiently significant. Furthermore, there seems to 
be no reasons for LSRs to lack this capability as it becomes 
available in other (non-label switched) IP routers."

it would have been interesting to sustain the reasoning with 
more tangible proofs - with the underlying question are we here
waiting for this doc. to make such experiment possible ?

much thanks,
- d.






<[e-mail]>
18/01/2007 11:49
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [e-mail]
        Subject:        RE: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG 
item


< Attachment smime.p7s removed >


Dimitri,

> discussion was led on the list mid november - no real
> conclusion or action where derived from the concerns
> expressed at that time

thanks for pointing out that this draft was also discussed elsewhere!

As for your specific points:

> > 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>

The process described in that document isn't official procedure yet, and
has raised significant concern in parts of the IESG. IMO it is unlikely
to proceed without major changes. Hence, it's questionable that we
should apply it here and now.

> [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)

I'm not quite sure I understand your point - are you saying that the
benefits of ECN for MPLS are unclear?

Thanks,
Lars
--
NEW EMAIL: [e-mail]
NEW MOBILE: [phone]
NEW JABBER: [e-mail]