The IESG has approved the following document: - 'Explicit Congestion Marking in MPLS ' <draft-ietf-tsvwg-ecn-mpls-02.txt> as a Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-mpls-02.txt Technical Summary RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This draft defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. Working Group Summary This document touches on subjects that fall into both the MPLS and TSVWG working groups. The agreement between the WGs was that the work would occur in TSVWG due to its expertise with ECN, with a joint Last Call in both working groups. This approach was followed. Document Quality This document has been reviewed in both the MPLS and TSVWG working groups. The document shepherd is not aware of any existing implementations. Personnel Lars Eggert <lars.eggert@nokia.com> reviewed this document for the IESG. RFC Editor Note Prior to the publication of draft-ietf-tsvwg-ecn-mpls-02.txt as an RFC, please make the following editorial changes: - expand ECMP on first use (section 2), i.e. replace the text "(ECMP)" with "(equal cost multi-path - ECMP)" - In the first paragraph of section 9.2, fix two typos by replacing "support ECN for single PHB" with "support ECN for a single PHB" and "accomplished by simply allocated" with "accomplished by simply allocating" - In the Security Considerations section, replace the final paragraph with the following slightly longer and, we hope, clearer version: An ECN sender can use the ECN nonce [RFC3540] to detect a misbehaving receiver. The ECN nonce works correctly across an MPLS domain without requiring any specific support from the proposal in this draft. The nonce does not need to be present in the MPLS shim header to detect a misbehaving receiver. As long as the nonce is present in the IP header when the ECN information is copied from the last MPLS shim header, it will be overwritten if congestion has been experienced by an LSR. This is all that is necessary for the sender to detect a misbehaving receiver. If there were a need for an ECN nonce in the MPLS shim header (e.g. to detect if one LSR was erasing the markings of an upstream LSR in the same domain), we believe this proposal does not preclude the later addition of an ECN nonce capability for specific DSCPs, just as it does not preclude any other use of the EXP codepoints. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
