Subject: L2VPN (Re-)charter: Service Convergence

From: Shane Amante <[email-masked]>
Date: Wed, 02 Apr 2008 08:02:38 -0600

Loa, Florin, Ali,

------Loa wrote------
 > - I'm a bit uncertain about whether there are one or two multi-homing
 >   scenarios in the text
 >   -- VPLS using multi-homed CEs
 >   -- multi-homed VPLS solutions

See Florin's suggested text below.  I think Florin is suggesting to 
clarify that we need both, (if I interpret your 2nd bullet correctly).

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

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?

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

------Ali wrote------
 > v) "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."
 >
 > AS> We should create another bullet to include multi-homing between two
 > or more VPLS networks.

Ali: I think you're asking for the same thing as Florin, (see above). 
If not, please clarify further.

Thanks,

-shane

---

From: "BALUS Florin" <[email-masked]>
Date: Wed, 2 Apr 2008 16:39:48 -0500

Shane,
See in-line... 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Shane Amante
> Sent: Wednesday, April 02, 2008 7:03 AM
> To: [email-masked]
> Subject: L2VPN (Re-)charter: Service Convergence
> 
> Loa, Florin, Ali,
> 
> ------Loa wrote------
> See Florin's suggested text below.  I think Florin is 
> suggesting to clarify that we need both, (if I interpret your 
> 2nd bullet correctly).
> 
> 
> ------Florin wrote------

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

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

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.

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.

> page, then I think we can tighten the suggested text a little further.

I hope the above answer addressed this one too.

---

From: Shane Amante <[email-masked]>
Date: Wed, 2 Apr 2008 21:48:15 -0600

Florin,

Please see below.

On Apr 2, 2008, at 3:39 PM, BALUS Florin wrote:
[--snip--]
> 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---

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

> connected to 2 VPLS PEs in domain 2.

Same question as above, specifically: hasn't l2vpn-signaling already  
addressed this?

> I hope the above answer addressed this one too.

Not yet, but we're getting there.  :-)

Thanks,

-shane

---

From: "BALUS Florin" <[email-masked]>
Date: Thu, 3 Apr 2008 04:07:08 -0500

Shane,
See below.. 

> From: Shane Amante [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2008 8:48 PM
> To: BALUS Florin
> Cc: [email-masked]
> Subject: Re: L2VPN (Re-)charter: Service Convergence
> 
> Florin,
> 
> Please see below.
> 
> >> Can you clarify this further?  Specifically, do you mean the 
> >> following two cases:
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.

> > not be enough for the interconnection of two VPLS mesh 
> domains: i.e.  
> > the

---

From: Shane Amante <[email-masked]>
Date: Mon, 7 Apr 2008 23:20:48 -0600

Hi Florin,

Please see below.

> totally eliminate single point of failure at both sides.

So, you're thinking of something similar to what's illustrated in  
Section 11.3 and/or 11.4 of draft-ietf-pwe3-redundancy-bit-00?  I  
think this raises the complexity vs. today's architecture of a full- 
mesh of only active PW's between a set of VPLS PE's with l2vpn- 
signaling to resolve a backup path when there is a failure of the  
primary path over the PSN.

It would be useful to hear from others if there is a need for this or,  
instead, it can be solved for with multi-homed CE's to two, different  
PE's.  For now, I'm still leaning toward the original text (which  
doesn't include multi-homed VPLS meshes), unless we hear from others  
on the need to add redundant meshes between VPLS domains.  Here's the  
original text.
---cut here---

Thanks,

-shane