答复: Comments on draft-rabadan-l2vpn-evpn-optimized-ir-00

[Lizhenbin <[e-mail]>]

Hi Rabadan,

Thanks for your detailed clarification about the difference between draft-rabadan-l2vpn-evpn-optimized-ir-00 and draft-zhang-l2vpn-evpn-selective-mcast-01. It seems reasonable that they are used for difference application scenarios. But I am sorry that I proposed the inappropriate draft in the comment:) The L2VPN draft should be draft-li-l2vpn-evpn-mcast-state-ad-01. This draft is to advertise the state information for the leaf node of the EVPN along with the Inclusive Multicast Ethernet Tag route. The possible application scenarios is to save bandwidth for ingress replication and facilitate the egress PE protecion for P2MP MPLS. For draft-li-l3vpn-mvpn-role-state-ad-02, we proposed the role information to be advertised in the Intra-AS I-PMSI A-D route. At the beginning, we think the role information for EVPN maybe not necessary comparing with BGP-based L3VPN since the unknown unicast always exists in the EVPN and every PE should be the root node. So it is only necessary to define the state information for the leaf node. In the optimized-ir draft, you proposed the role information to be advertised in the solution of central multicast replication. If the solution can be accepted, we hope that the generic solution can be worked out to advertise the possible role information or state information to cope with all possible optimization scenarios for inclusive multicast trees in EVPN. Then it decouples the role/state information with tunnel information. If so, the tunnel type defined in the RFC6514 can be reused and the new defined  role/state information community can be used for both EVPN and BGP-based MVPN. It is not necessary to define the new tunnel type (AR) which may be only used for the IR optimization solutions proposed by you.







Best Regards,

Robin



















________________________________

发件人: Rabadan, Jorge (Jorge) [[e-mail]]
发送时间: 2014年7月24日 12:55
收件人: Lizhenbin
抄送: [e-mail]
主题: Re: Comments on draft-rabadan-l2vpn-evpn-optimized-ir-00

Robin,

The scope of the current version of the optimized-ir draft is EVPN and ingress replication for layer-2 BUM traffic. So I won’t comment on the l3vpn draft for the moment.
As for draft-zhang-l2vpn-evpn-selective-mcast-01, I understand it tries to add selective multicast trees to EVPN, which I agree is something that was missing compared to RFC7117 for VPLS.

Selective multicast trees optimize the transport of specific IP multicast streams, setting up a different tree (type p2mp, IR, etc) to only those nodes interested in those IP multicast streams.
The optimized-ir draft addresses different issues. It actually modifies the IR tunnel type for inclusive multicast trees (BUM traffic). Because in reality we are just creating a different version of an IR tunnel:

  *   We still use the inclusive multicast route (because it will still tell the ingress PE where to send the BUM traffic)
  *   We add a new tunnel type (because it is no longer IR) and new flags in the reserved bits of the PMSI tunnel attribute.

This new tunnel type (AR) and the AR-type field can actually be used in draft-zhang-l2vpn-evpn-selective-mcast-01 for selective multicast trees if we needed to do the same optimization for selective multicast trees that use IR.

I hope that explains better why we are not using a separate route-type for this.
As for the compatibility, the solution is completely backwards compatible with the existing EVPN implementation, and it does not clash with MVPN or VPLS-MCAST as described in the draft:

  *   we are defining a new tunnel type, which should be discarded by PEs not supporting the draft
  *   we are defining some flags, which are not clashing with the “L” flag defined in RFC6514, that you also use in the selective mcast tree draft

I hope this helps clarifying the draft.
Thank you.
Jorge


From: Lizhenbin <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 23, 2014 at 10:09 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Comments on draft-rabadan-l2vpn-evpn-optimized-ir-00


Hi authors,

To follow up on my comments in the l2vpn meeting, following two drafts proposed in L2VPN WG and L3VPN WG are for your reference:

-- draft-li-l3vpn-mvpn-role-state-ad-02
-- draft-zhang-l2vpn-evpn-selective-mcast-01
The role information is truly a possible way to help optimize the BUM traffic in EVPN. Regarding the possible solutions, I have following more comments:

-- It is better to work out a generic role-info advertisement solutions based on all possible application scenarios.

-- Taking into account compatibility, it is better to define a new route type for NLRI or a new attribute to advertis the role information. The extension of PMSI Tunnel attribute may proposes compatibility issue for BGP-based MVPN defined in RFC 6514.





Regards,

Zhenbin(Robin)