Re: [re-ECN] Conex charter - now in External Review

[Bob Briscoe <[e-mail]>]

Stewart,

First, thanks for taking the trouble to state the concerns of the 
IESG and continue engaging in the debate.
Next, inline...

At 09:17 29/04/2010, Stewart Bryant wrote:

>>     (I also note that Stewart asked about MPLS forwarding: that's a
>>quite separate question which may deserve more of an answer than
>>I have already given...)
>Let me explain why I keep asking about MPLS.
>
>The stated purpose of CONEX is to provide visibility of congestion 
>state within the network.
>
>A very large fraction of provider networks use MPLS as their primary 
>forwarding mechanism.
>
>In those networks there will only be visibility of the congestion 
>state at the network ingress and egress unless an MPLS solution is designed.
>
>If the intent is to design a mechanism that works under the 
>assumption that congestion state will normally only be visible at 
>network boundaries, then that should be in the charter.

I'd agree if you had said "...under the assumption that congestion 
state will normally only be visible at IP nodes, e.g. network boundaries,..."

That's why the charter says "at IP nodes". It'd be wrong to limit 
ourselves only to network boundaries - they aren't the only IP nodes. 
ConEx might be used on every node in a network of IP-enabled RFID 
readers for some use no-one has even thought of yet. We mustn't 
confuse the way many commercial networks are built with all possible 
uses of IP.

Nonetheless you are right in one sense. All known use-cases of ConEx 
info are at trust boundaries (BRAS, GGSN, homegateways, border 
routers etc). But we don't need to say this in the charter, because 
there's no need to preclude use-cases at IP nodes just because they 
aren't trust boundaries.

>If the intent is not to make that assumtion, then we should have a 
>very high degree of confidence that we can find a viable MPLS solution.

ConEx visibility works *over* MPLS, but I agree it doesn't need to be 
visible *at* MPLS nodes.


>Bob's answer to MPLS in Anaheim was to take it out of scope, but 
>that does not address  the central of whether the technology is 
>viable for deployment without MPLS support.

The technology is certainly viable without MPLS support. This really 
is a non-issue. I thought I had made that clear.

Whether you are asking about MPLS support for ECN [RFC5129] *under* 
ConEx or ConEx support *in* MPLS, ConEx is viable without either.

I can explain in more detail if nec. (I can paste diagram & text I 
already have prepared, because it's not as straightforward as the 
above sentence implies, altho it's a good-enough summary).

HTH

Again, thanks for taking the time to consider this carefully.




Bob


>- Stewart
>_______________________________________________
>re-ECN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design