CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt
Sasha Vainshtein <Sasha@AXERRA.com> Tue, 11 November 2003 21:02 UTC
From: Sasha Vainshtein <Sasha@AXERRA.com>
Subject: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt
Date: Tue, 11 Nov 2003 23:02:00 +0200
Lines: 106
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1255"
Cc: Alik Shimelmits <alik@AXERRA.com>, "Stewart Bryant (E-mail)" <stbryant@cisco.com>, "Prayson Pate (E-mail)" <prayson.pate@overturenetworks.com>, "PWE3 WG (E-mail)" <pwe3@ietf.org>, "David Sinicrope (E-mail)" <David.Sinicrope@Ericsson.com>
X-From: pwe3-admin@ietf.org Tue Nov 11 22:26:09 2003
Return-path: <pwe3-admin@ietf.org>
To: "Yaakov Stein (E-mail)" <yaakov_s@Rad.co.il>
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Status: O
X-Message-ID:
Message-ID: <20140418091714.2560.24281.ARCHIVE@ietfa.amsl.com>
Yaakov and all, I'd like to present the technical problem I have with the current text of draft-stein-pwe3-pwce2e-00.txt and options for solving this problem. My problem is with the following para in Section 3: <quote> The ideal way of handling a PWCE2E packet is to have the CE perform the service specific encapsulation and to prepend the (inner) PW label, but no (outer) MPLS transport labels. The PE, which participates in the provider network signaling, then adds the appropriate MPLS labels as required. <end quote> IMO, it is easy to see why this will not work as written. Please consider the following use case: 1. There are three CEs (CE-1, CE-2 and CE-3) attached to 3 PEs (PE-1, PE-2 and PE3 respectively). 2. In each case the link between CE-i and PE-i is a "single-hop" link (i.e., there are no LSRs in the path, but there may be L2 switches - Ethernet, FR/ATM etc). 3. You want to run two PWs: a) PW-12 runs between CE-1 and CE-2 b)PW-13 runs between CE-1 and CE-3. How can PE-1 (which both these PWs have to cross on their ways to their peer CEs) know which transport labels to add to packets received from CE-1? This decision CANNOT be based on the PW labels in these packets, because these labels are independently allocated by CE-2 and CE-3 respectively, so that nothing prevents them from being equal (accidentally or else). And inspection of the encapsulated data will not help either. (BTW, this is exactly the difference between MPLS and, say, FR or ATM: in the latter cases, DLCI or VCI/VPI values are unique on the attachment link and known to the PE, in the former case they are not.) How can this be fixed? I see three ways to do so. 1. Limit this case to one PW per CE. IMO, this is a very problematic limitation (one could say, that it is ultimately non-scalable!) and does not justify any action wrt the existing documents. 2. Allow the CE to push both the PW and transport labels on top of the payload and PWE3 control info. This would make it equivalent to the "normal" PW,and no technical changes in the architecture doc are required. The transport label can be obtained in many different ways, including usage of the MPLS UNI (as suggested by David Sinicrope). 3. Use PW stitching. This would introduce a new element in the PWE3 architecture - the Pseudo-Wire Stitching Function (PSF) - located in the PEs. The PSF would operate like following: a) Terminate a "usual" PW running between two PEs adjacent to the CEs in question. Note that the PEs must exchange their incoming PW labels for this PW just as in the "normal" case b) Terminate the "spoke" PW between the CE and its adjacent PE. This PW would not require transport labels because the CE<-->PE transport LSPs are just one hop, and PHP can be applied to them. The PW labels for the spoke PWs would be exchanged between the CE and its adjacent PE in the usual way. c) Stitch the spoke PW with the PE-PE PW. Such a stitching would: * Leave the PW packet payload and control info (if any) intact * Swap the inner label * In one direction (CE-->PE), push the transport label(s) required for the PE-PE PW. Opposite to the PW IWFs, one and only one PSF type is required. The resulting architecture resembles the Hierarchical VPLS defined in draft-ietf-l2vln-vpls-ldp-01.txt (hence the term "Spoke PW"). Its advantage stems from moving the service-specific IWF functionality towards the CE (and hence may be of special importance for TDM PWs), while possibility of misconfiguration (e.g., connection of IWFs with different service types) should be considered as a disadvantage. Another disadvantage, of course, is introduction of a new (albeit simple) architectural element in the high-speed data plane. IMO, any technical changes in the architecture document should be considered only if we reach a conclusion that advantages of the PW stitching option outweigh its disadvantages. Hope these notes would be helpful. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular)
- CE-to-CE PWs, Hierarchical VPLS and Pseudowire St… Sasha Vainshtein
- RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowir… Yaakov Stein
- RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowir… Yaakov Stein