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

[Sasha Vainshtein <[e-mail]>]

Peterm,
Sorry I have mixed HVPLS and DVPLS.
I'll check the references (as I have said) and respond accordingly.

----------------------------------------------------------------------------
--------
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 2:19 AM
> To: Sasha Vainshtein
> 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
> 
> 
> 
> 
> > -----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
> > > > 
> > > 
> > 
>