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

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Wed, 6 Nov 2013 20:09:08 +0000

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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 7 Nov 2013 04:08:04 +0000

Hi Jorge,

Thanks for your comments. Please refer to my responses in line ...

>reader. It would also help when describing what kind of multi-homing is

Sure, we can add a diagram to it.

>families, BGP will not compare them for any purposes.

The text doesn't say "BGP" should give preference. It says "PE" should
give preference.

>when the EVPN route is withdrawn but not the BGP-AD route.

That's fine.

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

We will add this sentence.

>- Wrong reference -> ingress replication is not an RFC4447 concept but

OK.

>mac-mobility ext-comm for PBB-EVPN AND an LDP MAC withdrawal to the VPLS

OK.

>- also, single-active mh should also be possible in this scenario for

If you're referring to VPLS PEs, then that imposes the VPLS-MH mechanism
to be implemented on EVPN PEs which we don't want to impose this burden.

>should be removed or explained with clarity. (PBB-)VPLS PEs do not support

It is possible to do that and that's why it is "MAY". But it adds
considerable complexity on PBB-EVPN PEs. So, I will take it out.

Cheers,
Ali