Re: L2VPN (Re-)charter: Service Convergence

[Shane Amante <[e-mail]>]

Hi Florin,

Please see below.

On Apr 3, 2008, at 3:07 AM, BALUS Florin wrote:
> 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.

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

Thanks,

-shane




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