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

[Robert Raszuk <[e-mail]>]

Hi,

I support to accept this draft as WG document in either L3VPN or MPLS WG.

Regards,
R.


> 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.
>
>
>