Subject: RE: draft-lasserre-vkompella-ppvpn-vpls-04.txt

From: "Ron Haberman" <[email-masked]>
Date: Mon, 24 Mar 2003 22:09:11 -0500

-----Original Message----- 
	From: Rahul Aggarwal [mailto:[email-masked]] 
	Sent: Mon 3/24/2003 7:54 PM 
	To: Wei Luo 
	Cc: Vach Kompella; Ppvpn 
	Subject: Re: draft-lasserre-vkompella-ppvpn-vpls-04.txt

On Mon, 24 Mar 2003, Wei Luo wrote:

>
>
> Rahul Aggarwal wrote:
> >
> > On Mon, 24 Mar 2003, Wei Luo wrote:
> >
> > > Rahul,
> > >
> > > > A local PE clearly has to know if the remote PE is capable of doing MAC
> > > > address learning over a PW that it has signaled. Else it cannot use that
> > > > PW for sending VPLS traffic to the remote PE. Hence the differentiation
> > > > you talk about is needed and that is what I meant to convey in my comment
> > > > in the WG meeting. Its preferable to convey this in the FEC and it
> > > > probably relates to issue #2, though I don't have a strong opinion.
> > >
> > > What's the reason the local PE has to know whether the remote PE is capable of
> > > learning MAC address or not?  Isn't that some matter of the remote PE?
> >
> > There is no reason for the local PE to flood packets over the PW if the
> > other end can't really participate in the VPLS over that PW.
>
> For unknown unicast and broadcast packet, you will have to flood it regardless
> of the capability of the remote end, won't you?  Otherwise, you lose packets and
> have a connectivity problem.

>Agreed. But if the other end can't learn over that PW, its not really
>participating in the VPLS..

Ron> unless another bridge is connected to the PW (either internally or though another device). That bridge might be learning. A good example is a bridge connected to a VPLS cloud though a PW.   

>
> > > In the actual ethernet environment, an ethernet switch does not have to know
> > > whether it connects to another ethernet switch (capable of learning MAC address)
> > > or a dumb repeater (incapable of learning MAC address) on the other side of the
> > > wire before it sends/receives traffic to/from it.
> >
> > Do we need to make VPLS
> > > different from it?
> > >
> >
> > The same PW can be used for VPLS, VPWS, hierarchical VPLS etc. Knowing the
> > forwarder capabilities on that PW can help in flooding optimization, split
> > horizon checks and adds robustness. IMHO there is no point in bringing up
> > the PW if the forwarder capabilities at either end don't match..
>
> Shouldn't we use some kind of capability TLV in this case, which has more
> extensibility and better semantics than PW type?

Very true. This was well summarised by Eric in his response on this
issue..

rahul

> ---Wei

---

From: Rahul Aggarwal <[email-masked]>
Date: Mon, 24 Mar 2003 19:19:20 -0800 (PST)

> Ron> unless another bridge is connected to the PW (either internally or though another device). That bridge might be learning. A good example is a bridge connected to a VPLS cloud though a PW.   

True. I would consider the PW to be participating in the VPLS in that case
and it should be signaled appropriately. Similar situation also arises in
hierarchical VPLS.