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

["David Sinicrope" <[e-mail]>]

The MPLS UNI that Sasha is referring to is on the MPLS&FR Alliance
website:
http://www.mplsforum.org/tech/MPLS_FR202.0.1.pdf

It allows a provider network to present multiple TE LSPs to a CE device
over one interface.  Essentially these can be used as the transport
tunnels for the PWs.  The UNI provides LSPs for transport in a way
similar to Frame Relay PVCs and ATM PVCCs.   Currently the transport
LSPs are "PVC-like" in that they are provisioned between two CEs.
Similar to the FR UNI, there is no routing information/protocol passed
on the CE-PE interface, so the provider topology and routing information
is not exposed to the CE.  In addition to the transport LSPs there is a
LSP status protocol that is based on LDP.  It provides information about
the transport LSPs that are available on the CE-PE interface.  The
transport LSP information can be provisioned in the CEs and verified
with the status protocol or learned from the status protocol.

After hearing Yaakov's presentation Monday night, it seemed to me that
the UNI might be a good solution.  

-David

-------------------------------------------------------
David Sinicrope
Ericsson IPI
Email: [e-mail]
Phone: [phone]
Fax: [phone]
ECN: 802 29967


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