I am not sure how this document moved so quickly from its status as contentious WG document to being laid before the IESG for consideration, but I don't believe we ever received answers to serious questions regarding backwards compatibility. The draft claims to solve the following problem : According to the MPLS-TP requirement document [RFC5654], it is necessary that MPLS-TP mechanisms and capabilities be able to interoperate with the existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] architectures appropriate. Whatever "architectures appropriate" means ... (another sign of the haste with which this was prepared.) However, it accomplishes exactly the opposite. It breaks interoperability with existing PW implementations. The true goal of the draft appears a bit later on : The inconsistency between the usage of the GAL with MPLS PWs and MPLS-TP PWs may cause unnecessary implementation differences and is in disagreement with the MPLS-TP requirements. Accordingly, the draft allows PWs to indicate the associated channel by using the GAL, (i.e., making it a generic associated channel, rather than a PW associated channel). This indeed enhances interoperability with all the (presently nonexistent) MPLS-TP implementations, but completely breaks interoperability with the very broad installed base of PW implementations. Why is this the case ? The draft mandates the GAL appearing at the bottom of stack In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). Bottom of stack has been the label position of the PW label for many years, and this position is mandated by multiple RFCs, e.g. 3985 and 4447 Note that the PW label must always be at the bottom of the packet's label stack. Present PW implementations receiving the PW label with stack bit cleared, and a GAL at the bottom position will choke and, at best, discard the packet. At worst, the GAL may coincide with a legitimate PW label, and the customer will be flooded with garbage. This issue can not be avoided by limiting the use of this technique to "new" MPLS-TP based scenarios, since PWs can be set up to cross from MPLS-TP domains into traditional ones. Y(J)S -----Original Message----- From: pwe3-bounces@xxxxxxxx [mailto:pwe3-bounces@xxxxxxxx] On Behalf Of The IESG Sent: Friday, August 12, 2011 22:24 To: IETF-Announce Cc: pwe3@xxxxxxxx Subject: [PWE3] Last Call: <draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt> (Using the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed Standard The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Using the Generic Associated Channel Label for Pseudowire in MPLS-TP' <draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@xxxxxxxx mailing lists by 2011-08-26. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the requirements for using the Generic Associated Channel Label (GAL) in Pseudowires (PWs) in MPLS-TP networks, and provides an update to the description of GAL usage in [RFC5586] by removing the restriction that is imposed on using GAL for PWs especially in MPLS-TP environments. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf