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

[IJsbrand Wijnands <[e-mail]>]

Yakov,

Thanks for your comments;

Maybe its best if we view this draft not as a 'VPN' solution, but as a solution that uses VRF's to implement a service.

As I tried to explain before, this is not a solution that is meant to offer as a generic VPN service to end customers, but a solution used by a provider to internally partition services using VRF's.

Maybe my statement that this solution is to be used in a VPN environment was wrong and caused confusion. From the providers deployment POV, this is not an end customer VPN service.

The MVPN procedures you reference below just don't apply to this draft.

Thx,

Ice.



On 22 Apr 2012, at 15:31, Yakov Rekhter wrote:

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