About draft-sajassi-l2vpn-evpn-vpls-integration-00

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

Ali and draft authors,

Some comments about the draft.

General comments:

1) Very good draft and very well explained, as expected. The first thing
that I thought when I was beginning to read it is that the draft proposed
a sort of gateway function between EVPN and VPLS, which is not the case as
later explained. I believe a diagram would help clarifying this to the
reader. It would also help when describing what kind of multi-homing is
expected to work or not.

Specific comments:

2) Page 3:
"When a (PBB-)EVPN PE receives both a VPLS AD route as well as an EVPN
   Inclusive Multicast route from a given remote PE for the same VPN
   instance, it MUST give preference to the EVPN route for the purpose
   of discovery."

This is confusing. VPLS AD and EVPN incl. mcast routes belong to separate
families, BGP will not compare them for any purposes.

3) Page 4
"- If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD
   route from the same PE and a pseudowire is setup to that PE, then the
   (PBB-)EVPN PE MUST deactivate that pseudowire.
   - If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD
   route from the same PE, then the (PBB-)EVPN PE MUST ignore the VPLS
   AD route."

Suggested text:
"- If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD
route from the same PE and a pseudowire is setup to that PE, then the
(PBB-)EVPN PE MUST bring that pseudowire operationally down.
- If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD
route from the same PE, then the (PBB-)EVPN PE will setup the pseudowire
but MUST keep it operationally down"

Reason: consistency. The same behavior must be observed for potential
FEC128 pseudowires between (PBB-)EVPN PEs. It also simplifies procedures
when the EVPN route is withdrawn but not the BGP-AD route.

4) Page 4:
"When the (PBB-)EVPN PE receives traffic over the pseudowires, it
   learns the associated MAC addresses in the data-plane. This is
   analogous to dynamic learning in IEEE bridges."

Suggested additional text:
"The MAC addresses learnt and associated to the pseudowires will NOT be
advertised in the control plane to any remote (PBB-)EVPN PE."

Reason: this has to be clearly stated. Otherwise MAC duplication might
occur.

5) Page 5:
"3.3.1 Ingress Replication The procedures for multicast operation on the
   (PBB-)VPLS PE, using ingress replication, are per [RFC4447] and [PBB-
   VPLS]."

- need to modify format
- Wrong reference -> ingress replication is not an RFC4447 concept but
RFC4761/4762.

6) Page 3:
"In case of single-active redundancy, the participant VPN instances
   MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as
   single-active redundancy is employed by (PBB-)EVPN PEs"

- need to clarify that, in case of ESI link failure, the (PBB-)EVPN PEs
will send a BGP mass-withdraw to the EVPN peers OR MAC advertisement with
mac-mobility ext-comm for PBB-EVPN AND an LDP MAC withdrawal to the VPLS
peers.

- also, single-active mh should also be possible in this scenario for
BGP-AD PEs.

7) Page 3:

"8. In case of all-active redundancy, the participant VPN instances
   MAY span across (PBB-)EVPN and (PBB-)VPLS PEs."

- requirement 8 is contradicting 7 and making both statements confusing. 8
should be removed or explained with clarity. (PBB-)VPLS PEs do not support
all-active MH today.

Thank you.

Jorge