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

["Rabadan, Jorge (Jorge)" <[e-mail]>]

Robin,

While I personally believe draft-zhang-l2vpn-evpn-selective-mcast is needed, I also think draft-li-l2vpn-evpn-mcast-state-ad-01 is not adding anything that you can’t do today with the existing EVPN implementations based on the evpn draft rev 07, for optimizing BUM transport. Even for the egress protection, I don’t see the benefit.

Please correct me if I’m wrong: draft-li-l2vpn-evpn-mcast-state-ad proposes the addition of an extended community where you use 1 bit to signal the multicast state (interest for BUM) to the ingress PE, in both, inclusive multicast routes and AD routes. These are the reasons why I think this is not required:

- If the egress PE is not interested in BUM traffic for a given <evi, eth-tag>, it can simply NOT advertise the inclusive multicast for that <evi, eth-tag>. The ingress PE won’t send BUM traffic to that <evi, eth-tag>. This works today and there is no need for anything else IMHO.
- If the egress PE is not interested in BUM for a given <evi, esi>, what is the point of advertising the multicast state of that particular ESI?:
a) normally the evi on the egress PE has more ESIs or single-home connections, so the ingress PE will send the BUM anyway and regardless of the mcast state of the <evi, esi>
b) if there is no other ESIs/single-home CEs in the <evi, eth-tag>, as I said above, the egress PE can simply not advertise the inclusive multicast route.

The optimized-ir draft defines two mechanisms:

  1.  Assisted-replication for IR (orthogonal to the multicast state of a given <evi, eth-tag>)
  2.  Pruned-Flood-Lists (PFL) —> it does not signal interest to receive BUM, but it signals the interest of a given <evi, eth-tag> for receiving B/M or U individually. As I said, the lack of interest for BUM can simply be signaled by withdrawing/not advertising the inclusive multicast route for the <evi, eth-tag>.

Now, for application #2, you can argue that the flags can be included in an additional extended community instead of the PMSI Tunnel Attribute. The reason is purely efficiency: an extended community is 8 more bytes. Using the PMSI TA you add zero bytes. In your draft, you are using 1 bit out of 8 additional bytes, which is highly inefficient.

More comments in-line.
Thank you,

Jorge

From: Lizhenbin <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 24, 2014 at 10:52 AM
To: Jorge Rabadan <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: 答复: Comments on draft-rabadan-l2vpn-evpn-optimized-ir-00


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.

OK, no problem. It sounded a bit weird that you wanted to compare that one ;-)


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.

Please see above above the ingress replication. For the egress protection, I don’t see a much of a benefit.


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.

We are going to improve the draft in future revisions. Since we use the PMSI Tunnel Attribute, in theory you could reuse it in VPLS, even for selective PMSIs and maybe other technologies.
We are of course willing to accept ideas and contributions if we all decide something else is needed.


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.

As discussed, the new tunnel type (AR) is required because it is no longer IR and also to make sure the solution is compatible with existing EVPN implementations. The PFL flags can potentially be used with any other tunnel type too.








Best Regards,

Robin



















________________________________

发件人: Rabadan, Jorge (Jorge) [[e-mail]<mailto:[e-mail]>]
发送时间: 2014年7月24日 12:55
收件人: Lizhenbin
抄送: [e-mail]<mailto:[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)