Re: L2VPN (Re-)charter: Service Convergence

[Shane Amante <[e-mail]>]

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


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