Hi Pekka Regarding your following remark: >However, to be clear, I have no objection to using the ECN field(s) if >that does not hinder the current use (or lack thereof) of ECN. What I >specifically don't want is to define new fields for PCN, especially >extension headers or IP options. I should have been clearer with my >objection. I assume that you also have no objection on using the DSCP fields for this purpose. Best regards, Georgios On 2/20/2007, "Pekka Savola" <pekkas@xxxxxxxxxx> wrote: >On Mon, 19 Feb 2007, Black_David@xxxxxxx wrote: >>>> [logical components being:] encoding and transport along forward >>>> path from marker to egress, metering of congestion information at >>>> the egress, and transport of congestion information back to the >>>> controlling ingress. >>> >>> I'd like to see it explicitly stated that transporting congestion >>> information in the (metered) IP packets themselves is out of scope. >> >> Forward transport of the basic congestion information has to be in >> scope as Fred has pointed out. Backwards transport needs to be scoped >> by application scenario - for example, backwards transport via SIP >> is clearly out of scope for the initial PCN work. OTOH, not specifying >> how to actually move any of this information around would turn PCN >> into the moral equivalent an IRTF Research Group, which (IMHO) would >> be bad - at the end of the day, PCN needs to produce something that >> actually works (need "running code" in addition to "rough consensus"). > >It seems that are assuming the transport needs to happen in the packet >itself. While this is a possible approach, I don't see that it needs >to be the only one. For example, a mechanism where the mutually >trusting network components would have another channel to convey this >information (e.g., using SNMP, IPFIX, or the like) might also apply. > >However, to be clear, I have no objection to using the ECN field(s) if >that does not hinder the current use (or lack thereof) of ECN. What I >specifically don't want is to define new fields for PCN, especially >extension headers or IP options. I should have been clearer with my >objection. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >_______________________________________________ >PCN mailing list >PCN@xxxxxxxx >https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf