Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network
RFC 6391

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    pwe3 mailing list <pwe3@ietf.org>,
    pwe3 chair <pwe3-chairs@tools.ietf.org>
Subject: Protocol Action: 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network' to Proposed Standard (draft-ietf-pwe3-fat-pw-07.txt)

The IESG has approved the following document:
- 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched
   Network'
  (draft-ietf-pwe3-fat-pw-07.txt) as a Proposed Standard

This document is the product of the Pseudowire Emulation Edge to Edge
Working Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/


Technical Summary

   Where the payload of a pseudowire comprises a number of distinct
   flows, it can be desirable to carry those flows over the equal cost
   multiple paths (ECMPs) that exist in the packet switched network.
   Most forwarding engines are able to hash based on MPLS label stacks
   and use this mechanism to balance MPLS flows over ECMPs.

   This document describes a method of identifying the flows, or flow
   groups, within pseudowires such that Label Switching Routers can
   balance flows at a finer granularity than individual pseudowires.
   The mechanism uses an additional label in the MPLS label stack.

Working Group Summary

   The WG process was smooth.

   An IPR disclosure was made after this document had completed IETF last call. A new IETF last call
   was immediately made specifically calling out the IPR disclosure as the reason. The last call
   announcment was copied to the PWE3 working group mailing list. No comments of any type were
   received during the second last call.

Document Quality

   There are no concerns with document quality.

Personnel

   Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.
   Adrian Farrel (adrian@olddog.co.uk) is the responsible AD.

RFC Editor Note

Section 1.1
OLD
   A similar design for general MPLS use has
   also been proposed [I-D.kompella-mpls-entropy-label], Section 9.
NEW
   A similar design for general MPLS use has
   also been proposed [I-D.kompella-mpls-entropy-label], see Section
   9 of this document.
END

Section 1.2
s/it will always be will preceded/it will always be preceded/

Section 1.2
OLD
   This can be prevented by setting the flow LSE TTL to 1,
   thereby forcing the packet to be discarded by the forwarder.  Note
   that this may be a departure from considerations that apply to the
   general MPLS case.
NEW
   This can be prevented by setting the flow LSE TTL to 1,
   thereby forcing the packet to be discarded by the forwarder.  Note
   that setting the TTL to 1 regardless of the payload may be considered
   a departure from the TTL procedures defined in [RFC3032] that apply to
   the general MPLS case.
END

Section 1.2
OLD
   This document does not define a use for the TC bits (formerly known
   as the EXP bits) in the flow label.  Future documents may define a
   use for these bits, therefore implementations conforming to this
   specification MUST set the TC bits to zero at the ingress and MUST
   ignore them at the egress.
NEW
   This document does not define a use for the TC field [RFC5462] 
   (formerly known as the EXP bits [RFC3032]) in the flow label.  Future
   documents may define a use for these bits, therefore implementations
   conforming to this specification MUST set the TC field to zero at the
   ingress and MUST ignore them at the egress.
END

Section 2
OLD
it is required that the NSP
NEW
it is REQUIRED that the NSP
END

Section 4
OLD
   The absence of a FL Sub-TLV indicates that the PE is unable to
   process flow labels.  A PE that is using PW signalling and that does
   not send a FL Sub-TLV MUST NOT include a flow label in the PW packet.
   A PE that is using PW signalling and which does not receive a FL Sub-
   TLV from its peer MUST NOT include a flow label in the PW packet.
   This preserves backwards compatibility with existing PW
   specifications.
NEW
   The absence of a FL Sub-TLV indicates that the PE is unable to
   process flow labels.  An ingress PE that is using PW signalling
   and that does not send a FL Sub-TLV MUST NOT include a flow label
   in the PW packet. An ingress PE that is using PW signalling and
   which does not receive a FL Sub-TLV from its egress peer MUST NOT
   include a flow label in the PW packet. This preserves backwards 
   compatibility with existing PW specifications.
END

Section 4.1
OLD
   o  FL (value 0x17) is the flow label sub-TLV identifier assigned by
      IANA (seeSection 11 ).
NEW
   o  FL (value 0x17) is the flow label indicator sub-TLV identifier 
      assigned by IANA (see Section 11).
END


OLD
7.  OAM
NEW
7.  Operations, Administration, and Maintenance (OAM)
END


Section 7
OLD
   +-------------------------------+
   |                               |
   |      VCCV Message             |  n octets
   |                               |
   +-------------------------------+
   |   Optional Control Word       |  4 octets
   +-------------------------------+
   |      Flow label               |  4 octets
   +-------------------------------+
   |      PW label                 |  4 octets
   +-------------------------------+
   |      Router Alert label       |  4 octets
   +-------------------------------+
   |      MPLS Tunnel label(s)     |  n*4 octets (four octets per label)
   +-------------------------------+


                    Figure 4: Use of Router Alert Label
NEW
   +-------------------------------+
   |                               |
   |      VCCV Message             |  n octets
   |                               |
   +-------------------------------+
   |   Optional Control Word       |  4 octets
   +-------------------------------+
   |      Flow LSE                 |  4 octets
   +-------------------------------+
   |      PW LSE                   |  4 octets
   +-------------------------------+
   |      Router Alert LSE         |  4 octets
   +-------------------------------+
   |      MPLS Tunnel LSE(s)       |  n*4 octets (four octets per label)
   +-------------------------------+


                    Figure 4: Use of Router Alert Label
END

Section 8.5 Final line.
Delete "In a"

Section 11 first paragraph
NEW
   IANA maintains the "Pseudowire Name Spaces (PWE3)" with sub-registry
   "Pseudowire Interface Parameters Sub-TLV type Registry". IANA has 
   made an early allocation from this registry for the Flow Label 
   indicator sub-TLV type.
END


Section 12
OLD
   The congestion considerations applicable to PWs as described in
   [RFC3985] and any additional congestion considerations developed at
   the time of publication apply to this design.
NEW
   The congestion considerations applicable to PWs as described in
   [RFC3985] apply to this design.
END


Authors' Addresses

OLD
   Email: Alcatel-Lucent vach.kompella@alcatel-lucent.com
NEW
   Email: vach.kompella@alcatel-lucent.com
END

OLD
   Email: joe.regan@alcatel-lucent.comRegan
NEW
   Email: joe.regan@alcatel-lucent.com
END


IANA Note

   Please note that the registry used is under the Expert Review allocation policy.
   One of the designated experts is Stewart Bryant who is principal editor of this document.
   Please use the alternate expert, Danny McPherson.