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

["Busschbach, Peter B (Peter)" <[e-mail]>]

> -----Original Message-----
> From: Sasha Vainshtein [mailto:[e-mail]]
> Sent: Tuesday, November 11, 2003 3:02 PM
> To: Yaakov Stein (E-mail)
> Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate 
> (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail)
> Subject: [PWE3] CE-to-CE PWs, Hierarchical VPLS and 
> Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt
> 
> 
> 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. 

Sasha,

I believe that option 3 is identical to the Distributed VPLS model described in section 5.5 of draft-ietf-l2vpn-signaling-00.txt.

IMO, CE-CE PWs is just one example of situations that require multi-hop PWs. 

draft-ietf-l2vpn-signaling-00.txt talks about splicing PWs. You talk about stitching PWs. In both cases the solution sounds kludgy, to say the least. However, if you look at these multi-hop PWs as regular LSPs established along a multi-hop path, everything is pretty much straightforward. Setup of such multi-hop LSPs would require a protocol like CR-LDP or RSVP. RSVP is in my view the preferred solution, but CR-LDP would be closer to the current control draft.

In any case, as I said in another email, I would prefer it if we would solve the multi-hop issue before progressing the control draft. The response to that email was that it is not clear that people are interested in the multi-hop solution. I would argue that Yaakov's contribution shows that there is interest.

Peter

>    
> Hope these notes would be helpful.
> --------------------------------------------------------------
> --------------
> --------
> With best regards,
>                           Sasha Vainshtein
> email:   [e-mail]
> phone:  [phone] (office)
>             [phone] (home)
>             [phone] (cellular)
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pwe3
>