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

["Yaakov Stein" <[e-mail]>]

Sasha, 

See a few comments below,


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

[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?

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.

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

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

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

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.

[Y(J)S] Very.