Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00

[IJsbrand Wijnands <[e-mail]>]

Dear L3VPN,

We presented draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 to the MPLS WG last IETF in Taipei and received a comment that this should be discussed in L3VPN. As it looks there is not going to be a L3VPN meeting in Paris, for that reason I'm sending out this email to solicit input on this draft.

This draft describes a solution to be used in a VPN environment, but it is not intended to be used as a generic solution for Multicast VPNs. It is for specific deployments where traffic is bundled in 'service' VPNs within a Providers network, following similar procedures and rationale as described in draft-ietf-mpls-mldp-in-band-signaling-05. These VPNs are not generic customer VPNs, but used to transport content such as IPTV or financial data through a Providers network.

The basic idea is that the ingress PE's VRF RD is added to the mLDP FEC opaque encoding to make it unique and VPN specific. This follows the same model as described in draft-ietf-mpls-mldp-recurs-fec-04 section 3. We had a similar discussion regarding the use of the RD in the opaque encoding and decided to accept it as WG document in the MPLS WG.

Some may say this solution does not follow the multicast procedures as documented in draft-ietf-l3vpn-2547bis-mcast-10, and for that reason should not be allowed.
However,

1. This is not any different from draft-ietf-mpls-mldp-recurs-fec-04 section 3.
2. This draft is driven by customer interest.
3. This solution relies on existing IP-VPN BGP procedures without additional extensions.

For that reason we like to see draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 progress as WG document in the MPLS WG.

We welcome your feedback,

Thx,

The authors.