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(_at_)ietf(_dot_)org
[mailto:pwe3-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: Friday, August 12, 2011 22:24
To: IETF-Announce
Cc: pwe3(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org mailing lists by 2011-08-26. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf