RE: L2VPN (Re-)charter: Service Convergence

["BALUS Florin" <[e-mail]>]

Shane,
See below.. 

> -----Original Message-----
> From: Shane Amante [mailto:[e-mail]] 
> Sent: Wednesday, April 02, 2008 8:48 PM
> To: BALUS Florin
> Cc: [e-mail]
> Subject: Re: L2VPN (Re-)charter: Service Convergence
> 
> Florin,
> 
> Please see below.
> 
> On Apr 2, 2008, at 3:39 PM, BALUS Florin wrote:
> [--snip--]
> >> ------Florin wrote------
> >>> The L2VPN WG scope includes the following:
> >>> [..]
> >>> 6. Improved service convergence for multi-homed CE's to VPLS PE's.
> >>>   Specifically, upon failure of a primary path from a CE
> >> to VPLS PE,
> >>>   initiate a rapid switch-over to an alternate path.  If required,
> >>>   interactions with native service-layer resiliency
> >> mechanisms will be
> >>>   provided via solutions from other IETF WG's such as PWE3.
> >>>
> >>> FB> Suggest we modify the text to include also
> >> multi-homing between 2
> >>> VPLS domains, see below an example of text:
> >>> 6. Improved service convergence for multi-homing
> >> solutions: CEs to VPLS
> >>> PEs or between VPLS domains.
> >>
> >> Can you clarify this further?  Specifically, do you mean the 
> >> following two cases:
> >> a)  One CE to two different VPLS PE's in a single AS; and,
> >> b)  One CE to two different VPLS PE's, each in a different AS?
> >>
> >
> > Not really. What I had in mind was more along the following:
> > a) CEs multi-homed to different VPLS PEs
> > b) a VPLS domain multi-homed to another VPLS domain: e.g. a VPLS  
> > mesh in
> > domain 1 multihomed to a VPLS mesh in domain 2.
> > Examples of criteria that may define what a VPLS domain is:  
> > geographical
> > (metro, national, international), administrative different
> > organizations/providers) etc...
> 
> With respect to (b), isn't one (major?) aspect an Inter-AS 
> use case?   
> If so, hasn't that already been addressed by Sections 4.1 & 4.2 of  
> draft-ietf-l2vpn-signaling-08?  From Section 4.2 of that draft, (see  
> second sentence):
> ---cut here---
> Note that the procedures described here will result in the splicing  
> points (S-PEs in the terminology of 
> [I-D.ietf-pwe3-ms-pw-arch]) being  
> co-located with the ASBRs. It is of course possible to have multiple  
> ASBR-ASBR connections between a given pair of ASes. In this case a  
> given PE could choose among the available ASBRs based on a range of  
> criteria, such as IGP metric, local configuration, etc., 
> analogous to  
> choosing an exit point in normal IP routing. The use of 
> multiple ASBRs  
> would lead to greater resiliency (at the timescale of BGP routing  
> convergence) since a PE could select a new ASBR in the event of the  
> failure of the one currently in use.
> ---cut here---
> 
> 
This addresses the case of redundant MS-PW path between two VPLS PEs.
Assume you have the following scenario:
VPLS Mesh 1 - PE1 - redundant MS-PW path as in l2vpn signaling - PE2 -
VPLS Mesh 2.
If PE1 or PE2 fails there is no way to communicate between the 2 meshes,
it does not matter how many paths you have in between them.

We need to have at least other 2 gateway Pes - e.g. PE1' and PE2' - to
totally eliminate single point of failure at both sides.

> >> Also, correct me if I'm wrong, but PWE3 has already covered
> >> multi-homing of a MTU-s to two, different PE-rs'es in
> >> draft-muley-pwe3-redundancy-02?
> >>  Or, is there addt'l work that L2VPN WG needs to take care of
> >> specifically for that case?
> >
> > draft-muley-pwe3-redundancy (adopted as PWE3
> > draft-ietf-pwe3-redundancy-00.txt) can be definitely applied to  
> > optimize
> > the procedures described in section 10.2 of RFC 4762 (VPLS MTU-s to
> > PE-rs resiliency). Still I think there is a need to have a 
> discussion
> > about usage in a VPLS context to ensure interoperability, 
> including an
> > update on how to reflect the PW transitions in LDP MAC Flush.
> 
> The current draft-muley already discusses that.  Are you suggesting  
> the VPLS use-cases be pulled out into a separate draft and put in  
> L2VPN, (which we'd add a goal/milestone for)?
> 
> 
> > Also this sort of resiliency (1 MTU-s to 2 PE-rs, triangle 
> like) might
> > not be enough for the interconnection of two VPLS mesh 
> domains: i.e.  
> > the
> > MTU-s will be a single point of failure. More like a square
> > interconnection is required here where 2 VPLS PEs in domain 1 are
> > connected to 2 VPLS PEs in domain 2.
> 
> Same question as above, specifically: hasn't l2vpn-signaling already  
> addressed this?
> 
> 
> 
> >>> Specifically, upon failure of a primary
> >>> path from a between CEs and VPLS PEs or between VPLS
> >> domains, initiate a
> >>> rapid switch-over to an alternate path. If required,
> >> interactions with
> >>> native service-layer resiliency mechanisms will be provided via
> >>> solutions from other IETF WG's such as PWE3.
> >>> FB>
> >>>
> >>>
> >>> The L2VPN WG currently works on the following tasks:
> >>> [..]
> >>> - Identify requirements for multi-homing of CE's to VPLS PE's.
> >>>  elements.  Based on these requirements, define solutions for
> >>>  achieving fast convergence after a switchover to an
> >> alternate path,
> >>>  for example through optimized MAC flushing within a VPLS domain.
> >>>
> >>> FB> Suggest changing this one to the following text:
> >>> - Identify requirements for different multi-homing
> >> solutions: i.e. CEs
> >>> to VPLS Pes or between VPLS domains. Based on these
> >> requirements, define
> >>> solutions for achieving fast convergence after a switchover to an
> >>> alternate path, for example through optimized MAC flushing
> >> within a VPLS
> >>> domain.
> >>> FB>
> >>
> >> I have the same question here as I do above.  Once we're 
> on the same
> >> page, then I think we can tighten the suggested text a little  
> >> further.
> >>
> >
> > I hope the above answer addressed this one too.
> 
> Not yet, but we're getting there.  :-)
> 
> Thanks,
> 
> -shane
>