[Tsvwg] Protocol Action: 'Explicit Congestion Marking in MPLS' to Proposed Standard

[The IESG <[e-mail]>]

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 <[e-mail]> 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.