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

[Sasha Vainshtein <[e-mail]>]

Peter,
Thank you for a prompt response.

I'll check  your reference to hierarchical VPLS in 
draft-ietf-l2vpn-signaling-00.txt
However, I do not think that Option 3 is really identical to 
hierarchical VPLS because the PSF is service-agnostic
and does not look at any part of the native frame.
I would say it sounds like a hierarchical VPWS.

I would appreciate references to multi-hop LSPs if you can provide them.

Wrt interest - or lack thereof - based on Yaakov's draft, the crucial
question, IMO, is: what justifies support of Option 3 when Option 2
does the same job as well? Saving one label stack entry on the CE-PE
packet clearly does not. And, from little I know about MPLS UNI
(David is the expert here), it allows you to obtain a valid transport
label without the need to learn the core topology. It is also a clear-cut
control plane solution, without the need for a new function (PSF) in the
high-speed data plane.

Please note that I do not reject Option 3 out of hand. I simply try to
understand its advantages (and disadvantages:-).

At the same time I feel pretty sure that Option 1 is a dead-end.

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [e-mail] <mailto:[e-mail]> 
phone:  [phone] (office)
            [phone] (home)
            [phone] (cellular)


> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:[e-mail]]
> Sent: Wednesday, November 12, 2003 1:01 AM
> To: Sasha Vainshtein; Yaakov Stein (E-mail)
> Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail);
> PWE3 WG (E-mail); David Sinicrope (E-mail)
> Subject: RE: [PWE3] CE-to-CE PWs, Hierarchical VPLS and Pseudowire
> Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt
> 
> 
> 
> 
> > -----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
> > 
>