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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce