Subject: RE: draft-lasserre-vkompella-ppvpn-vpls as working group draft

From: "Serbest, Yetik" <[email-masked]>
Date: Wed, 16 Apr 2003 17:29:27 -0500

I would like to second that. 

Thanks,
yetik

-----Original Message-----
From: Matt Squire [mailto:[email-masked]] 
Sent: Tuesday, April 15, 2003 7:08 AM
To: 'Rick Wilder'
Cc: [email-masked]
Subject: Re: draft-lasserre-vkompella-ppvpn-vpls as working group draft

The Laserre/VKompella draft should definitely progress as a working 
group draft.  Its a solid technical contribution with a lot of support 
behind it.

- Matt

Olen Stokes wrote:
> I would also like to support making this a working group draft.
>  
> Cheers,
> Olen
> 
>     -----Original Message-----
>     *From:* Rick Wilder [mailto:[email-masked]]
>     *Sent:* Thursday, April 10, 2003 11:20 AM
>     *To:* [email-masked]
>     *Subject:* draft-lasserre-vkompella-ppvpn-vpls as working group 
> draft
> 
>     As noted in the minutes, at the San Francisco meeting strong
>     interest was expressed in pursuing the
>     "draft-lasserre-vkompella-ppvpn-vpls" as a working group draft. We
>     agreed to finalize that decision only after the WG participants who
>     weren't there could have a say.
> 
>      
> 
>     So, if there are opinions that have not been heard, now is the time,
>     and this list is the place. Let's set a one-week limit to conclude
>     this issue.
> 
>      
> 
>     Rick
> 
>      
> 
>     
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> -------
> 
>      From the minutes:
> 
>      
> 
>     Alex: For a document to become a WG draft, it doesn't have to be
>     100% correct.  It can become a WG document if it is a good start.
> 
>     Matt: I wanted to make the same comment.
> 
> 
>     [snipped]
> 
>      Marco: asked for show of hands to make this a wG draft.
>     Strong interest was shown in room. Further discussion on the list.
> 
>      
>

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Thu, 17 Apr 2003 15:01:50 -0400

Yetik,
As an one of the editor of
draft-augustyn-ppvpn-l2vpn-requirements-02.txt, I assume you care about
the requirements in that draft.
From the requirements draft, Section 5.8:
"In case of VPLS, the L2VPN service MUST ensure that loops be
prevented."

I agree that it is a fundamental requirement that bridging loops be
handled in a VPLS solution. As we know loops can have a devastating
effect on a bridged network.

So, has this point been carefully considered for the VPLS drafts being
proposed to be progressed?

I think the VPLS drafts being considered here (using full-meshed with
split-horizon) are not able to handle common scenarios/requirements
leading to loops and causing network meltdowns. 

This point has been raised before by several people but it still has not
been addressed. If this mandatory requirement (not a minor detail or
rare scenario) is not addressed and we still progress these drafts what
is the message to the industry? That it's ok to continue pushing
solutions that don't meet fundamental requirements? 

Thanks,
Cheng-Yin

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 17 Apr 2003 15:58:02 -0700

Cheng-Yin,

As I mentioned before, the issue of customer dual-homing (either 
inter-provider or intra-provider) is one of the many bridging issues being 
discussed in 802.1ad and it is outside of the scope of IETF. The confusion 
in here is that you think IETF needs to be responsible for the entire 
end-to-end VPLS service. Whereas, IETF is only responsible for portion of 
it - e.g., LAN emulation part (refer to figure 3 l2vpn framework). The 
bridging portion is the responsibility of IEEE group as has been 
coordinated with them. So the requirements can be for an end-to-end 
service, but the end-to-end solution needs participation from MEF, IEEE, 
and IETF.

-Ali

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Thu, 17 Apr 2003 19:06:19 -0400

Ali,
Pls see my response to Yetik Serbest and Ben Schultz.
The looping issues may not all be addressed by 802.1ad.

Regards
Cheng-Yin

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 17 Apr 2003 16:28:18 -0700

Cheng-Yin,

I covered both of your points in details and if you still have concern, 
then reply directly to my email, tell me which portion of it is not clear 
and be specific please - saying split-horizon will not work due to 
congestion, will not cut it. If you have such a congestion that causes the 
traffic to get shut down (for several seconds - enough to cause 
dis-connectivity among endpoints) , then split-horizon is least of your 
problem !!!

Let me repeat my email again ...

==============================================

The issues that you are bringing up in here are not just specific to our 
draft but also applies to other drafts (e.g., draft-kompella-vpls, 
draft-gvpls, ).

If you have attended the IEEE 802.1 meeting, you should know that the first 
issue has been discussed there (both in the meeting as well as the mailing 
list) and there are two parts to it (and you only mention one of them):
a) how does SP deal with customer loops
b) how does SP react to customer TCN

This issue is being addressed in within the 802.1ad and it is pertinent to 
bridging aspect of VPLS which is being handled by IEEE. So lets not confuse 
the issue in here. There are many things regarding VPLS that are not 
addressed by any of the drafts. VPLS is an end-to-end service (from 
customer uni to customer uni), IETF only deals with the provisioning of 
this service over MPLS/IP network. This service consists of bridging 
portion that is being dealt with IEEE. If you look at the l2vpn framework, 
the PE device consists of bridging module and "LAN emulation" module. What 
you are talking about will be taken care by bridging module by IEEE.
Also what you are suggesting (e.g., SP participating in customer's STP) is 
not the answer !!! and this is not the right forum to discuss it either. It 
should be discussed in IEEE.

Regarding the second point, of a PW failure without restoration, I find it 
very interesting that we can rely on failure recovery mechanism in bridges 
but not in routers !!! One thing that routers are good at, is to find 
alternate routes in case of link or node failure !!!

-Ali

-Ali