Subject: revised draft-ietf-l2vpn-vpls-ldp-03.txt has been posted

From: "Vach Kompella" <[email-masked]>
Date: Mon, 26 Apr 2004 09:05:53 -0700

Adds the Generalized PWid FEC signaling, removes signaling VLAN tags,
cleans up references, cleans up the discovery section.

Vach Kompella
IP Division, Alcatel
[email-masked]
+1 650 237-5152

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 26 Apr 2004 11:39:44 -0700 (PDT)

Vach, Marc:

> cleans up references, cleans up the discovery section.

Whoops, didn't know you were spinning a new draft.  Some minor edits:

Last two sentences of section 10.2.2 (-02 version):

             To enable faster convergence, the PE3-rs device where the
   secondary pseudowire got activated may send out a flush message,
   using the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon
   receiving the message, PE-rs nodes flush the MAC addresses
   associated with that VPLS instance.

I remember reading on the L2VPN list that flushing MAC addresses was a
bad idea (Ali?) -- the thing to do is to age them faster.  So, when
you say "flush", do you mean flush or age quickly?

Also, reference to section 6 should really be to section 7.2.1 (in old
version).

Kireeti.
-------

---

From: "Vach Kompella" <[email-masked]>
Date: Mon, 26 Apr 2004 11:56:25 -0700

I thought the addition of the generalized FEC needed a new rev.

A flush should turn on a fast-aging as opposed to the normal slow-aging
timer, kind of replacing the TCN.

-Vach 

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]] 
> Sent: Monday, April 26, 2004 11:40 AM
> To: Vach Kompella
> Cc: [email-masked]
> Subject: Re: revised draft-ietf-l2vpn-vpls-ldp-03.txt has been posted
> 
> 
> Vach, Marc:
> 
> I remember reading on the L2VPN list that flushing MAC 
> addresses was a bad idea (Ali?) -- the thing to do is to age 
> them faster.  So, when you say "flush", do you mean flush or 
> age quickly?
> 
> Also, reference to section 6 should really be to section 
> 7.2.1 (in old version).
> 
> Kireeti.
> -------
>

---

From: Ali Sajassi <[email-masked]>
Date: Tue, 27 Apr 2004 12:54:55 -0700

>you say "flush", do you mean flush or age quickly?

Upon a failure of a non-redundant link, flushing MAC addresses is a bad 
idea since it creates intermittent broadcast storm. But flushing MAC 
addresses upon activation of a redundant link is the right thing to do in 
order to avoid black holing of user traffic.

-Ali

---

From: "Vishal Sharma" <[email-masked]>
Date: Wed, 28 Apr 2004 12:59:20 -0700

Vach et al,

With much discussion about discovery and failure, I went searching
for some of the discovery alternatives, listed in Sec. 6 of the
latest rev.

However, some of the refernces appear a bit outdated ...

*****
[BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network-
   based VPNs", draft-ietf-l3vpn-bgpvpn-auto-02.txt, Work in Progress, 
   April 2004. 

[LDP-DISC] "Discovering Nodes and Services in a VPLS Network", 
   draft-stokes-ppvpn-vpls-discover-00.txt, Work in Progress, June 
   2002. 
******

The latest BGP discovery doc. is at ver. 03., and I couldn't find
the latest LDP discovery document on the IETF drafts directory.

Has the name changed? How does one locate it?

-Vishal

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Vach Kompella
> Sent: Monday, April 26, 2004 9:06 AM
> To: [email-masked]
> Subject: revised draft-ietf-l2vpn-vpls-ldp-03.txt has been posted
> 
>