Subject: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 11 Nov 2003 23:02:00 +0200

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:   [email-masked]
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 12 Nov 2003 03:27:54 +0200

Sasha, 

See a few comments below,

<quote>

[Y(J)S]  You are assuming that these inner labels are
independently downstream allocated by CE2 and CE3,
which doesn't have to be the case. 

[Y(J)S] An easy fix is for PW labels to have "structure",
for example (what we do) is to use input-port + output port + serial-number.

[Y(J)S] All that is needed is for the PW labels to be unique in CE1.

How can this be fixed?

[Y(J)S] Agreed that this is very limited, although a common situation.

[Y(J)S] I don't want to make an MPLS stack here.

   

[Y(J)S] Very.

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 12 Nov 2003 04:26:50 +0200

[[Sasha]] I do not see this as ever becoming a standard approach.  PW labels
must be understood by the devices that terminate the pWs (in your case -
CE-2 and CE-3).These devices can have their own preferences regarding global
label space etc., and your "structured" labels can easily contradict these
preferences. Not every device is ready to receive and process any value
between 16 and 1M as a valid incoming labels (in fact, most don't). In
addition, you require the labels to be correctly interpreted in two points -
by the CE that terminates them and by the PE that adds transport labels
based on the PW ones. IMO, this is a fundamental contadiction with the MPLS
architecture and hence not acceptable. But let's, at least, present the
complete solution ("structured" non-local labels and all) and discuss it!
The draft did not ever mention "structured" labels (unless I missed
something), and I did not consider an option that clearly contradicts the
basics of the MPLS architecture.

[Y(J)S] But these are NOT MPLS labels, they are PW labels.
Why should PW labels be required to conform to the full MPLS
constraints?

[Y(J)S] What do we really need the PW label for? To diifferentiate
between multiple PWs going together in a tunnel between the same two devices.
For example, several E1s going between two points.
A very common solution is to use some coding of the port numbers
of these E1s.

<snip>

[[Sasha]] Franly I do not see it as a problem, but, if it is, let's solve it
in the specific devices that encounter it - this is definitely not a common
problem! 

[Y(J)S] Once again, the inner label is not a true MPLS label,
and I don't see the need to force it to be one.

Y(J)S