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

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 10 Feb 2012 12:19:25 +0100

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.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 20 Feb 2012 22:54:43 +0000

In my opinion, draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 fits well within MPLS WG. It adds to a MLDP set of procedures to allow "virtualization" of MLDP in-band signaling.
I am in support for progressing it in MPLS WG.

Regards,

Maria 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of IJsbrand Wijnands
> Sent: Friday, February 10, 2012 6:19 AM
> To: L3VPN mailing list
> Subject: Regarding draft-wijnands-mpls-mldp-vpn-in-band-signaling-00
> 
> 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,
> 
> For that reason we like to see draft-wijnands-mpls-mldp-vpn-in-band-
> signaling-00 progress as WG document in the MPLS WG.
>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 21 Feb 2012 02:14:54 -0500

I support progress of this document as WG document in the MPLS WG.
-- 
Regards,
Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Feb 2012 12:08:17 +0100

Hi,

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

Regards,
R.

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 21 Feb 2012 07:32:41 -0500

Support.

Cheers,
Rajiv

Sent from my Phone

On Feb 21, 2012, at 2:14 AM, "Jeff Tantsura" <[email-masked]> wrote:

>>> section 3.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 22 Feb 2012 05:05:31 -0800

Ice,

> 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 L3 VPN. 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
> 'service' VPNs within a Providers n twork, following similar
> procedures and rationale as described in draft-ietf-m
> pls-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.
> 
> 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.
> 
> reason should not be al lowed.
> 
> However,
> 
> draft-wijnands-mpls-mldp-vpn-in-band-signaling-00 progress as 
> WG document in the MPLS WG.

This draft, as you said above, "describes a solution to be used in
a VPN environment". Thus it is outside the scope of the MPLS WG (as
VPN is outside the charter of that WG).

If the authors want to progress this draft as a WG document,
then they should ask L3VPN WG to progress it as an L3VPN WG document
(as VPN is within the charter of that WG).

Yakov.

---

From: <[email-masked]>
Date: Mon, 27 Feb 2012 09:05:41 +0000

This fits well with several planned service implementations
I am in support for progressing it in MPLS WG.

Regards,

Andy

> customer VPNs, but used to transport content such as IPTV or financial data through a Providers network.
> 
> the opaque encoding and decided to accept it as WG document in the MPLS WG.
>