Subject: VC label assignment in LDP-VPLS

From: "Bala S. Venkata" <[email-masked]>
Date: Mon, 20 Feb 2006 21:22:40 -0800

Per LDP-VPLS draft Section 4.2 ("Address Learning"), "..reachability 
information is not advertised and distributed via a control plane". Now, 
how is the VC label (or the inner label) then decided (I assumed this 
much be exchanged in the control plane over the targeted ldp session) ? 
In a BGP_MPLS VPN each PE sends [<RD>:<SiteRoutes>, VPNLabel] to the 
remote in the control plane so that any traffic in the data plane to 
that site route would use that VPNLabel. Is there a mechanism similar to 
that for the two PW types (ethernet and ethernet-tagged)....but a PE 
cannot send [<Port1>.<VCLabel1>] because Port1 won't make sense to the 
remote PE ?

In section 4 the draft mentions that the AC could be "..an ATM PVC 
carrying Ethernet frames, etc., or even an Ethernet PW" besides an 
ethernet port. How can the remote PEs learn MAC addresses if the AC 
sends a non-ethernet frame ?

Thanks !

/bala

---

From: "Rajesh Pandey" <[email-masked]>
Date: Tue, 21 Feb 2006 12:08:37 +0530

Hi Bala,

Find my answers inline:

>> These are two different questions.
For reachability information answer lies in next line itself. Excerpt from
draft-ietf-l2vpn-vpls-ldp-08.txt:
"reachability information is not advertised and distributed via a control
plane.  Reachability is obtained by standard learning bridge functions in
the data plane."
Actually VPLS creates an emulated LAN segment for a given set of users and
performs the transparent bridging operations like a normal bridge: flooding,
learning, filtering, forwarding and aging. For more info regarding
transparent bridging operations you might be interested in reading 802.1D or
some similar doc.

>> For PW exchange related info you can go through
draft-ietf-pwe3-control-protocol-17.txt. This draft talks in detail about
these things.

> >> First thing to be noticed, MAC address learning/aging is done on a per
> pseudo-wire basis. The scope of the VPLS lies within the PEs in the service
> provider network not beyond. The PE performs forwarding of user data packets
> based on information in the Layer-2 header, such as a MAC destination
> address.  What CE sees a is just a bridge. Further, you cann't preclude
> customer access connections to be something specific, it may be different at
> different CE devices (e.g., Frame Relay, ATM, 802.1d, MPLS). You might be
> interested in going through draft-ietf-l2vpn-requirements-04.txt
>

Hope this helps.

Regards,
Rajesh

Thanks !