IETF Logo Mail Archive

Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 16 August 2011 17:01 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55321F8B52; Tue, 16 Aug 2011 10:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.954, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRcUwzioRWUm; Tue, 16 Aug 2011 10:01:57 -0700 (PDT)
Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 4F3AB21F8B47; Tue, 16 Aug 2011 10:01:56 -0700 (PDT)
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1313514149!40800009!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [147.234.242.235]
Received: (qmail 5681 invoked from network); 16 Aug 2011 17:02:29 -0000
Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-11.tower-21.messagelabs.com with SMTP; 16 Aug 2011 17:02:29 -0000
X-AuditID: 93eaf2e8-b7b3eae00000414f-8f-4e4a9becf855
Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id CB.CF.16719.CEB9A4E4; Tue, 16 Aug 2011 19:33:48 +0300 (IDT)
Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 16 Aug 2011 20:02:41 +0300
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "ietf@ietf.org" <ietf@ietf.org>
Date: Tue, 16 Aug 2011 20:02:20 +0300
Thread-Topic: IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Thread-Index: AcxcGBA21vETQ27uTwSWVgNiuD48+AAHMfDU
Message-ID: <A3C5DF08D38B6049839A6F553B331C760111EF7BD443@ILPTMAIL02.ecitele.com>
References: <A3C5DF08D38B6049839A6F553B331C760111EFA07C5F@ILPTMAIL02.ecitele.com>
In-Reply-To: <A3C5DF08D38B6049839A6F553B331C760111EFA07C5F@ILPTMAIL02.ecitele.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C760111EF7BD443ILPTMAIL02e_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURTmzszarDkxu2Vet4hprEBjZbcXG7lhRWRSZlv0IwobZ6+7U7sz 284YWlDaA3tq71IDzSzyEabZgx5U/jCUoCexaAWRRZlEiVH9KLuzUyZE99d3z/ed7xzuPYcm raUjbLQkaygsCwE+JpY60ts/YO+rzMxynO1Jcb1trqJcXWfrTK7S/lYqncyorf1OZIPVRSBN kGVFEzTEeZEquvnssLRJEAt5TvK6eSfPhQKCiIJI1ty8EAoh2cvPjeX+OWlYJskckkXFK8k+ N794xTK7yzVztt3Jz52S5Jw+J3alX1I5ZA8KUoALIlUVfIjDkXWtpL/yeT0R+ril4NX27aYi UObfC8w0ZGfAoztLYgw8Fj582YRxLG1lbwDYcOSJybgcB7DjW19UFcO6YUvDiygewybBO+WR qIhkrxKwpOopqRMUOxneHziHMU2PZufBxvYlhn4+jNR8IQw8DXY/uhX1YdjlsPrlPZOOrRg/ Li6mdGxmPfDH4EBUA3B3Xzsbo7kkmwC7eqoIo2sW1t58QBo4Hr5//dNk6OPh85ImYOgV2HRl 9+9aFthR3kMZ+kR493yEOgjGVgyzrRiWUjEsxYinwsixozEGngrPnf5AGtgOT/5so4bHq8GI epAoBUJabtDnmGZX8rVUJEoaCqBUUQm2AGOA3l0D3feT2wBLAz6OWbw7M8tqEjaphcE2kEgT fDyztRqHRuUq3kK/oPpzwvkBpLYBSJP8GAbkYY7xCoWbUVj5Qy3EH3CItI0UFTyqspYz3eH4 /4VPYPaJfUutrA+P5waEQij8x2c8TfOQaT6NS1jCyIcK8qSA9pcmaLPeRhxu47yuYdSQEFQl n8F3Ajv9obuqHVgpWZGRLYEha7CI1UX+fHnIR1+jbYODg70gAT/AaOaNbhWHl2zIqRcXIXCR rusZehG8RkOUrQj4Lhes96jgouNtR3r1maTGjAWcp8H8+fXKFk/6pwPitVxeWGMp8WizdjRv rFuYfWFinWdAs+3fStSVFrCJez+mH+6NfHqTtSTzxPViR/yllEVXuPa1AJo7V427fSavf5ez ZtypsmdxlgkCnZbDTMzpnHRMfJhcZnFXtu7JffeqladUv+BMIcOq8As0QBzmIQQAAA==
Cc: "mpls@ietf.org" <mpls@ietf.org>, Vladimir Kleiner <Vladimir.Kleiner@ecitele.com>, Idan Kaspit <Idan.Kaspit@ecitele.com>, Mishael Wexler <Mishael.Wexler@ecitele.com>, pwe3 <pwe3@ietf.org>, Oren Gal <Oren.Gal@ecitele.com>, John Shirron <John.Shirron@ecitele.com>, Rotem Cohen <Rotem.Cohen@ecitele.com>
Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2011 17:01:58 -0000

Hi all,
After having sent out my comments I've noticed that the specific example to illustrate the need to combine GAL and "flow label" was inaccurate.

A more relevant example would look like following (I do not include a diagram, but it can be easily provided if necessary)

 1.  A MS-PW:
    *   Starts at an S-PE that resides at the edge of an MPLS-TP domain (no ECMP)
    *   Crosses this domain and enters an IP/MPLS domain with ECMP enabled using a T-PE that resides at the age of these two domains
    *   Leaves this domain and enters a 2nd MPLS-TP domain (using the 2nd T-PE)
    *   Terminates on another S-PE at the edge of the 2nd MPLS-TP domain
 2.  The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertion and discard of "flow labels" at the two S-PEs. Note that:
    *   This does not violate the MPLS-TP restriction on ECMP: ECMP does not happen in he MPLS-TP domains
    *   T-PEs do not even have to be aware of flow labels
 3.  The operator also intends to operate some end-to-end OAM for this MS-PW using "GAL-in-PW". This results in a conflict since both GAL and "flow label" are defined (in the corresponding drafts) as bottom of stack.



IMHO this describes a realistic scenario where the two drafts are in controversy.

Regards,
     Sasha
________________________________
From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
Sent: Tuesday, August 16, 2011 4:26 PM
To: ietf@ietf.org
Cc: mpls@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen
Subject: [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

Hi all,

I would like to raise the following issue with regard to draft-ietf-pwe3-gal-in-pw<http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/?include_text=1>: controversy vs. draft-ietf-pwe3-fat-pw<http://datatracker.ietf.org/doc/draft-ietf-pwe3-fat-pw/?include_text=1> with regard to bottom-of-stack position.

As stated in the Introduction, this draft removes the restriction imposed by RFC 5586 on usage of Generic Associated Channel Label (GAL) in PWs. The corresponding text Section 4.2 of RFC 5586 states:
In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs.  It MUST always be at the bottom of the label stack    (i.e., S bit set to 1).

draft-ietf-pwe3-gal-in-pw proposed to replace the original text in RFC 5586 with the following

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).

I.e.,  while removing this restriction of 5586, it does not modify its requirement for the GAL being always at the bottom of the label stack.

At the same draft-ietf-pwe3-fat-pw (currently also in the IESG review) reserves the bottom of the PW stack for the PW flow labels, e.g., in Section 1.1:

This document describes a method of adding an additional label stack entry (LSE) at the bottom of stack in order to facilitate the load balancing of the flows within a PW over the available ECMPs.

One could argue that draft-ietf-pwe3-gal-in-pw only applies to MPLS-TP pseudowires, and that MPLS-TP does not use ECMP. IMHO and FWIW,
such an argument, were it presented, would be highly problematic, because:


1.       RFC 5960 (which defines the MPLS-TP data plane) did not define any differences between the PW data plane in IP/MPLS and MPLS-TP.

2.       One of the most popular scenarios for using multi-segment pseudowires is the case when an edge-to-edge service emulation crosses multiple IP/MPLS and MPLS-TP domains. In these scenarios, the flow label of draft-ietf-pwe3-fat-pw (inserted by a flow-aware T-PE at the edge of an IP/MPLS domain) would potentially compete with GAL (inserted by a T-PE at the edge of an MPLS-TP domain, e.g., for relying a PW status message that it has received over a Targeted LDP session from the IP/MPLS domain to a static PW status message to cross the MPLS-TP domain) for the bottom-of-stack position.

The issue I am raising Is not new. It has been actively discussed on the PWE3 mailing list with regard to adoption of draft-nadeau-pwe3-vccv-2 as a WG document, with arguments  for both the flow label and GAL taking the bottom-of-the-stack position. But, to the best of my understanding, consensus on this issue has not been reached.

Hopefully this comment will be useful.

Regards,
     Sasha


This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.


This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

v2.23.0 | Report a Bug | By Email