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

[Yakov Rekhter <[e-mail]>]

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 no t 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 n etwork, 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.
> 
> 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,
>

As you asked for feedback, here are few commends on the draft:

1. The following should be added to Abstract and Introduction:

  Procedures specified in this draft are not compatible with
  the standard MVPN procedures, as specified in [RFC6513, RFC6514].
  Thus, a PE router that implements procedures specified in
  this draft would not be able to interoperate with a PE
  router that implements the standard MVPN procedures.
 

2. From the draft:

                                                       For a variety of
   reasons (discussed in [I-D.ietf-l3vpn-2547bis-mcast]), this is not a
   suitable for a general purpose multicast VPN solution.  

The above is a bit confusing/misleading. The reason why this solution
is not suitable for a general purpose multicast VPN solution is
that it does not meet some of the mandatory requirements for 
multicast VPN solution, as stated in rfc4834. With this in mind
I would like the authors to replace the above with the following:

  The solution described in this draft is not suitable for a general
  purpose multicast VPN solution, as it does not meet multiple
  mandatory requirements for multicast VPNs specified in [rfc4834],
  such as (a) scalability, (b) support for MVPN customers running ASM, 
  (c) support for extranets, (d) support for tunneling technologies
  other than mLDP, etc..

3. From the draft:

   But the procedures described herein are much simpler than the 
   general purpose MVPN procedures, 

This is just a matter of opinion, and as such should be removed
from the draft.

4. From the draft:

   Due to the 1-1 mapping and the multicast source and group information
   being encoded in the mLDP FEC, there is deterministic mapping beween
   the multicast tree and the mLDP LSP in the core network.  This
   improves and simplifies fault resolution.

There is nothing in the general purpose MVPN procedures that
would prevent the same. Thus the same fault resolution could
be done with the general purpose MVPN procedures. With
this in mind I propose either (a) to delete the above text, or
(b) keep the above text, and add the following to the above text:

  The same fault resolution could be accomplished with the
  general purpose MVPN procedures.

5. From the draft:

   In order to use the mLDP in-band signaling procedures for a
   particular group address in a particular VPN, the Provider Edge (PE)
   routers that attach to that VPN MUST be configured with a range of
   multicast group addresses for which mLDP in-band signaling is to be
   enabled.  This configuration is per VRF ("Virtual Routing and
   Forwarding table", defined in [RFC4364]). For those groups, and
   those groups only, the procedures of this document are used instead
   of the general purpose Multicast VPN procedures. This configuration
   must be present in all PE routers that attach to sites containing
   senders or receivers for the given set of group addresses.

First of all, the document should spell out that configuring on a
PE "a range of multicast group addresses for which mLDP in-band
signaling is to be enabled" requires coordination between a
customer and a service provider.

Second, the document needs spell out the procedures for groups that
are not in this range. E.g., should traffic to these groups be
discarded ? Should this traffic be handled using standard MVPN
procedures ? Something else ?

6. As I said before, 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.