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 5: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.

My interpretation of HVPLS is that the N-PE (what you call PSF) performs a bridging function (i.e. a service-specific function), where as in DVPLS the N-PE merely splices PWs in a service-agnostic way.

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

RFC 3031, RFC 3209 and RFC 3212 :-)

A multi-hop PW is essentially an regular LSP. You may need to extend existing specs to deal with FECs that may contain non-routable information, perhaps along the lines of Ina Minei's draft that we discussed this morning. Apart from that, I don't see anything special.

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