Subject: Re: EVPN: MAC age

From: Lizhong Jin <[email-masked]>
Date: Tue, 3 Jul 2012 21:10:31 +0800

Hi Wim,
I have slightly different opinion about the aging. If the remote MAC
advertised by BGP is aged out by receiving node, how to learn the MAC
address again? Will the unknown unicast packet be broadcasted if aged out?
In my opinion, the control plane should maintain all the MAC address
advertised by BGP without aging, but the dataplane could maintain the
active MAC address only. When not matching for packet forwarding, lookup
the table in control plane, and install the corresponding active MAC entry
in dataplane.

Jakob's question is to ask for  adding an age time to the MAC NLRI. I do
not suggest to do that. If MAC address is aged out, how to handle the
potential unknow unicast packet?

Lizhong

> -------------------------------------
> Message: 1
> Date: Tue, 3 Jul 2012 10:28:38 +0200
> From: "Henderickx, Wim (Wim)" <[email-masked]>
> To: "[email-masked]'"
>         <[email-masked]>,     "[email-masked]
> '"
>         <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>
> Subject: Re: EVPN: MAC age
> Message-ID:
>         <
> [email-masked]
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> For remote mac addresses you can rely on bgp withdraws or do aging locally
> based on activity or both. Now given that you provide multi-pathing it is
> best to rely on bgp withdraw for remote mac addresses to ensure consistency
> accross all mes(es).
>
> Cheers,
> Wim
> _________________
> sent from blackberry
>
> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: Tuesday, July 03, 2012 10:19 AM
> To: Henderickx, Wim (Wim); Jakob Heitz <[email-masked]>
> Cc: [email-masked] <[email-masked]>
> Subject: RE: EVPN: MAC age
>
> Hi all,
> I have doubts regarding the statement in Wim?s message ?Aging is done in
> the same way as VPLS.?
>
> AFAIK VPLS implementations that learn MCA addresses from traffic typically
> maintain ?usage state? for learned MAC addresses i their data path so that
> only MAC addresses that have learned once but not seen for a long time are
> aged out.
>
> To the best of my understanding, in EVPN this would still work for MAC
> addresses learned from the local ACs, but not for MAC addresses that have
> been installed via the control plane. Or do I miss something substantial
> here?
>
> Regards,
>      Sasha
>
>
> Regards,
>      Sasha
>
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henderickx, Wim (Wim)
> Sent: Tuesday, July 03, 2012 10:11 AM
> To: Jakob Heitz; [email-masked]
> Subject: RE: EVPN: MAC age
>
> Aging is done in the same way as VPLS. You have a local age timer and if
> it expires the MAC address is withdrawn from the EVPN.
>
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jakob Heitz
> Sent: dinsdag 3 juli 2012 8:45
> To: [email-masked]
> Subject: EVPN: MAC age
>
> Is there a way to age out a MAC address in EVPN?
> Does the advertising MES just withdraw it when it ages out?
> Is there a possibility to add an age to the MAC NLRI?
> Or put an age into a BGP extended community?
>
> --
> Jakob Heitz.
>
>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 3 Jul 2012 15:17:09 +0200

See my reply to alex. The remote macs should controlled by bgp. The local mac can either be preregistered via a protocol or learned in the dataplane. For preregistration the protocol should take care of the aging while for dataplane learning dataplane aging is required.

Cheers,
Wim
_________________
sent from blackberry

From: Lizhong Jin [mailto:[email-masked]]
Sent: Tuesday, July 03, 2012 03:10 PM
To: [email-masked] <[email-masked]>; Henderickx, Wim (Wim)
Subject: Re: EVPN: MAC age

Hi Wim,
I have slightly different opinion about the aging. If the remote MAC advertised by BGP is aged out by receiving node, how to learn the MAC address again? Will the unknown unicast packet be broadcasted if aged out?
In my opinion, the control plane should maintain all the MAC address advertised by BGP without aging, but the dataplane could maintain the active MAC address only. When not matching for packet forwarding, lookup the table in control plane, and install the corresponding active MAC entry in dataplane.

Jakob's question is to ask for  adding an age time to the MAC NLRI. I do not suggest to do that. If MAC address is aged out, how to handle the potential unknow unicast packet?

Lizhong

-------------------------------------
Message: 1
Date: Tue, 3 Jul 2012 10:28:38 +0200
From: "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>'"
        <[email-masked]<mailto:[email-masked]>>,     "[email-masked]<mailto:[email-masked]>'"
        <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: Re: EVPN: MAC age
Message-ID:
        <[email-masked]<mailto:[email-masked]>>

For remote mac addresses you can rely on bgp withdraws or do aging locally based on activity or both. Now given that you provide multi-pathing it is best to rely on bgp withdraw for remote mac addresses to ensure consistency accross all mes(es).

Cheers,
Wim
_________________
sent from blackberry

From: Alexander Vainshtein [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 03, 2012 10:19 AM
To: Henderickx, Wim (Wim); Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: EVPN: MAC age

Hi all,
I have doubts regarding the statement in Wim?s message ?Aging is done in the same way as VPLS.?

AFAIK VPLS implementations that learn MCA addresses from traffic typically maintain ?usage state? for learned MAC addresses i their data path so that only MAC addresses that have learned once but not seen for a long time are aged out.

To the best of my understanding, in EVPN this would still work for MAC addresses learned from the local ACs, but not for MAC addresses that have been installed via the control plane. Or do I miss something substantial here?

Regards,
     Sasha

Regards,
     Sasha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, July 03, 2012 10:11 AM
To: Jakob Heitz; [email-masked]<mailto:[email-masked]>
Subject: RE: EVPN: MAC age

Aging is done in the same way as VPLS. You have a local age timer and if it expires the MAC address is withdrawn from the EVPN.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jakob Heitz
Sent: dinsdag 3 juli 2012 8:45
To: [email-masked]<mailto:[email-masked]>
Subject: EVPN: MAC age

--
Jakob Heitz.

---

From: Lizhong Jin <[email-masked]>
Date: Tue, 3 Jul 2012 21:40:16 +0800

Agree with the below statement now.

Thanks
Lizhong

On Tue, Jul 3, 2012 at 9:17 PM, Henderickx, Wim (Wim) <
[email-masked]> wrote:

> See my reply to alex. The remote macs should controlled by bgp. The local
> mac can either be preregistered via a protocol or learned in the dataplane.
> For preregistration the protocol should take care of the aging while for
> dataplane learning dataplane aging is required.
>
> Cheers,
> Wim
> _________________
> sent from blackberry
>
>
> *From*: Lizhong Jin [mailto:[email-masked]]
> *Sent*: Tuesday, July 03, 2012 03:10 PM
> *To*: [email-masked] <[email-masked]>; Henderickx, Wim (Wim)
>  *Subject*: Re: EVPN: MAC age
>
>  Hi Wim,
>>         <[email-masked]>,     "'
>> [email-masked]'"
>> For remote mac addresses you can rely on bgp withdraws or do aging
>> locally based on activity or both. Now given that you provide multi-pathing
>> it is best to rely on bgp withdraw for remote mac addresses to ensure
>> consistency accross all mes(es).
>>
>> Cheers,
>> Wim
>> _________________
>> sent from blackberry
>>
>> AFAIK VPLS implementations that learn MCA addresses from traffic
>> typically maintain ?usage state? for learned MAC addresses i their data
>> path so that only MAC addresses that have learned once but not seen for a
>> long time are aged out.
>>
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Henderickx, Wim (Wim)
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Jakob Heitz

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 07 Jul 2012 14:39:56 +0200

I have read the draft-mjsraman-l2vpn-vpls-tictoc-label-hop-00.txt.

It proposed an interesting solution to apply algorithmically computed 
VPN lable (for L2VPNs, but also possible for L3VPN) where inter-as 
option C is used.

However I have a fundamental question .. from who the draft is 
protecting the inter-as service ?

Who other then participating ISPs can spoof a value of VPN label ? If 
the solution is protecting from ISPs itself then I think it does not 
help at all as corresponding ISPs/SPs still have full access to their 
PEs and could inject packets to VPN sites at will.

Moreover main issue with option C is not security (at least for the last 
10+ years). Main issue with option C and MPLS is that participating 
providers need to inject into each other's network all of their 
participating PE's /32 addresses so the end to end MPLS LSP can be 
build. Originally that was recommended to be done by mutual 
redistribution to the IGP .. now the general recommendation is to use 
labeled BGP (both IBGP and EBGP).

So fundamental question to the authors ... who is the potential 
attacker/spoofer this draft is aiming to protect from ?

Best regards,
R.

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 8 Jul 2012 03:26:55 -0400

Another question.
How does this interact with ECMP flow hashing on LSRs, rfc6391 and draft-ietf-mpls-entropy-label?

--
Jakob Heitz.

On Jul 7, 2012, at 5:40 AM, "Robert Raszuk" <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,
R.