Subject: MAC route with IP

From: Jakob Heitz <[email-masked]>
Date: Mon, 12 May 2014 04:56:59 +0000

We have another issue
In section 10: ARP and ND, the draft says:

   If there are multiple IP addresses associated with a MAC address,
   then multiple MAC advertisement routes MUST be generated, one for
   each IP address. For instance, this may be the case when there are
   both an IPv4 and an IPv6 address associated with the MAC address.

   When the IP address is dissociated with the MAC address, then the MAC

   advertisement route with that particular IP address MUST be

   withdrawn.

If such a route is withdrawn and no MAC route without IP exists, then the MAC address will be forgotten. Therefore, we would like to add a sentence:

Whenever a PE advertises one or more MAC advertisement routes with IP address for a particular MAC address, it MUST also advertise one MAC advertisement route without an IP address for that MAC address.

Thanks,
Jakob.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 12 May 2014 05:33:54 +0000

Hi Jakob,

I believe the currency text is correct and sufficient. What use case do you have in mind?

EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MAC and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address from MAC-VRF only gets removed, when there is no more ARP entry with that MAC address.

Cheers,
Ali

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 11, 2014 9:56 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: MAC route with IP

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 12 May 2014 05:38:57 +0000

When the IP address is dissociated with the MAC address, but the MAC address still exits.

Cheers,
Jakob.

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; [email-masked]
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 12 May 2014 05:53:09 +0000

Yes, but that's the case when that MAC address is associated with other IP addresses per my example below. And as long as there are other ARP entry (or entries) for that MAC address after deleting that IP/MAC pair, the MAC address will remain in the MAC-VRF.

Cheers,
Ali

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 11, 2014 10:38 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: RE: MAC route with IP

Cheers,
Jakob.

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Sunday, May 11, 2014 10:34 PM
To: Jakob Heitz; [email-masked]<mailto:[email-masked]>
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 12 May 2014 05:59:14 +0000

People clear ARP caches when they get too big. When that happens, the bridge table may not be cleared at the same time or at all.
An ARP cache may have a different timeout than the bridge table.
A bridge can snoop ARP messages to learn bindings and those bindings can time out.
However, many other packets can come from the same MAC address, keeping the MAC alive in the bridge table. In this case, the MAC-IP binding will be lost without the MAC address itself being lost.
IP-MAC bindings can be learnt other than by snooping ARPs, by configuration, for example.
Such configurations can be removed.

Cheers,
Jakob.

From: L2vpn [mailto:[email-masked]] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); [email-masked]
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 12 May 2014 06:23:10 +0000

Ali,

there are at least two cases when receiving updates from peers which are tad hairy given the encoding:

1.      We receive a MAC/no-IP  & a set of MAC/IP routes & then someone just withdraws the MAC/no-IP.  It does not seem very logical that the MAC/IP routes are still valid to me or at least that could be emphasized in the draft that they do (i.e. all routes are truly independent).

2.      Since we have mac based disposition there is nothing that prevents a neighbor to advertise multiple MAC/IP routes with different labels.  It should obviously not imply that we have to lookup the IP address on the packet (if we even have one) to decide which label is needed.  Should all this labels be considered pointing to the same MAC & equivalent ? Such a condition considered invalid transient and MAC labels for this MAC ignored completely ?  What if we get one route with the label & another without ? We use the label nevertheless for the same MAC ?

And my final interesting observation:

               A single primary/single backup case would be simple & easy, the way the protocol spec stands today, I don't think there is anything that prevents it from operating in  multiple-primaries, multiple-backup mode  (as in two guys clear the single-active bits & all other set them) [unless I misunderstood something massively].   Do we load balance the primaries until both fail & then either flood (multiple backups) or fail back on the secondary ?

Otherwise, very good draft I think solving tons of hard problems in (for the customer and in terms of protocols mechanics) fairly elegant way.

--- tony
From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Sunday, May 11, 2014 10:53 PM
To: Jakob Heitz; [email-masked]
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Cheers,
Ali

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 May 2014 06:21:18 +0000

Jakob, Antoni:

Agreed that the ARP entries can timeout independent from the MAC table and thus the entries in MAC-VRF and ARP table can be deleted independent of each other. However, the existing text is still accurate. It already covers the scenario that is interest to you where there are multiple IP/MAC pair advertisement for a given MAC plus MAC-only advertisement. In such case, the withdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table.

I added the following couple of sentences to the end of 2nd para of section 10 for further clarification:

"If the receiving PE has already received a MAC-only advertisement for MACx in addition to the IPx/MACx advertisement, then when it receives a withdraw message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete the MACx entry from the MAC-VRF table unless it receives a withdraw message for MACx only."

Cheers,
Ali

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 11, 2014 10:59 PM
To: Jakob Heitz <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: RE: MAC route with IP

Cheers,
Jakob.

From: L2vpn [mailto:[email-masked]] On Behalf Of Jakob Heitz
Sent: Sunday, May 11, 2014 10:39 PM
To: Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>
Cc: Antoni Przygienda
Subject: RE: MAC route with IP

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 13 May 2014 16:06:21 +0000

inline

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Tuesday, May 13, 2014 8:45 AM
To: Antoni Przygienda; Jakob Heitz; [email-masked]
Subject: Re: MAC route with IP

Antoni,

From: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 11, 2014 11:23 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Jakob Heitz <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: MAC route with IP

Ali,

MAC/IP routes will be independent from MAC-only route. If both are advertised, then withdrawing the MAC/IP route should clean up the ARP table but not remove the entry in the MAC-VRF.
[Tony said] ack, I understood that & the draft read carefully states that in ARP/ND procedures. I would mildly suggest to explicitly state what you write in the draft prominently since this question will come up persistently and misinterpretation of that clause will cause hard-to-track interop problems.

The label represents the MAC address in case of label per MAC advertisement. So, even when you advertise multiple IP addresses for the same MAC, they all should use the same label.
[Tony said] the 'should' will not help resolve the possible issue. I would suggest for the draft to clearly state a 'SHOULD' and specify desired behavior when this clause is violated, as in: SHOULD/MAY log an error and MAY use any of the advertised labels.

For a given ES, all PEs should advertise the same redundancy group mode (either all-active or single-active mode) for that ES. Otherwise, an error should be logged.
[Tony said] Again, a 'SHOULD' in the draft would be good as well: "An error MUST be logged"  would be very desirable.

So, I agree with all you say, Ali, it's just I think this things deserve explicit statements in the draft due to potential of causing hard-to-track deployments bugs and therefore easing up the life of the operators chasing stuff like this (e.g. the last one could be a genuine hard-to-track misconfig).

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 May 2014 15:45:08 +0000

Antoni,

Ali,

               A single primary/single backup case would be simple & easy, the way the protocol spec stands today, I don’t think there is anything that prevents it from operating in  multiple-primaries, multiple-backup mode  (as in two guys clear the single-active bits & all other set them) [unless I misunderstood something massively].   Do we load balance the primaries until both fail & then either flood (multiple backups) or fail back on the secondary ?

Cheers,
Ali

--- tony

Cheers,
Ali

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 13 May 2014 16:28:21 +0000

My concern is not that a MAC/IP withdrawal might delete a MAC only route.
It is that there might not be a MAC only route there at all.

Thanks,
Jakob.

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Monday, May 12, 2014 11:21 PM
To: Jakob Heitz; [email-masked]
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 May 2014 16:30:23 +0000

From: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 13, 2014 9:06 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Jakob Heitz <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: MAC route with IP

inline

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Tuesday, May 13, 2014 8:45 AM
To: Antoni Przygienda; Jakob Heitz; [email-masked]<mailto:[email-masked]>
Subject: Re: MAC route with IP

Antoni,

Ali,

OK. I have already added couple of sentences to clarify this per my previous reply to Jakob.

The label represents the MAC address in case of label per MAC advertisement. So, even when you advertise multiple IP addresses for the same MAC, they all should use the same label.
[Tony said] the ‘should’ will not help resolve the possible issue. I would suggest for the draft to clearly state a ‘SHOULD’ and specify desired behavior when this clause is violated, as in: SHOULD/MAY log an error and MAY use any of the advertised labels.

I'll take it under consideration.

For a given ES, all PEs should advertise the same redundancy group mode (either all-active or single-active mode) for that ES. Otherwise, an error should be logged.
[Tony said] Again, a ‘SHOULD’ in the draft would be good as well: “An error MUST be logged”  would be very desirable.

OK. We'll add that.

Cheers,
Ali

So, I agree with all you say, Ali, it’s just I think this things deserve explicit statements in the draft due to potential of causing hard-to-track deployments bugs and therefore easing up the life of the operators chasing stuff like this (e.g. the last one could be a genuine hard-to-track misconfig).

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 May 2014 16:34:48 +0000

Jakob,

If there is no MAC-only route, then it is fine as well – e.g., we don't need the MAC-only route for the MAC/IP route to work. If there is only MAC/IP route, the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However, if there are both MAC/IP route and MAC-only route, and one of them gets withdrawn, then the FIB entry will still exist. This is the correct behavior.

Cheers,
Ali

Date: Tuesday, May 13, 2014 9:28 AM

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 13 May 2014 16:37:15 +0000

How do we write code for the receiver if it receives different labels on the different MAC routes?
Say we receive, in order:
MAC1/IP1 Label1
MAC1/no-IP Label2
MAC1/IP2 Label1

The sender might have sent, in order:
MAC1/IP1 Label1
MAC1/IP2 Label1
MAC1/no-IP Label2

A route reflector can reflect routes in a different order than it received them.
Which label should the receiver program?

Thanks,
Jakob.

From: Antoni Przygienda
Sent: Tuesday, May 13, 2014 9:06 AM
To: Ali Sajassi (sajassi); Jakob Heitz; [email-masked]
Subject: RE: MAC route with IP

inline

Antoni,

Ali,

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 May 2014 16:42:53 +0000

The labels should all be the same. In case of EVI-based disposition, the label identifies the EVI and a MAC lookup is performed based on the MAC. Thus, the order of routes in which they are received, doesn't matter.

Cheers,
Ali

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 13, 2014 9:37 AM
To: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: MAC route with IP

Thanks,
Jakob.

From: Antoni Przygienda
Sent: Tuesday, May 13, 2014 9:06 AM
To: Ali Sajassi (sajassi); Jakob Heitz; [email-masked]<mailto:[email-masked]>
Subject: RE: MAC route with IP

inline

Antoni,

Ali,

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 13 May 2014 16:43:50 +0000

Then if a sender withdraws a MAC/IP route, say because the ARP cache timed out, but the MAC is still known, it must send a MAC only route before it withdraws the MAC/IP route.
Now, because route reflectors can reorder route advertisements (but not announce/withdraw of the same route), the receiver can receive the withdrawal of the MAC/IP before it receives the announcement of the MAC only.
To prevent this glitch, I propose

Thanks,
Jakob.

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Tuesday, May 13, 2014 9:35 AM
To: Jakob Heitz; [email-masked]
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Jakob,

If there is no MAC-only route, then it is fine as well - e.g., we don't need the MAC-only route for the MAC/IP route to work. If there is only MAC/IP route, the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However, if there are both MAC/IP route and MAC-only route, and one of them gets withdrawn, then the FIB entry will still exist. This is the correct behavior.

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 13 May 2014 16:49:00 +0000

Error handling for the error of receiving different labels: Treat-as-withdraw ?

Thanks,
Jakob.

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Tuesday, May 13, 2014 9:43 AM
To: Jakob Heitz; Antoni Przygienda; [email-masked]
Subject: Re: MAC route with IP

Cheers,
Ali

Thanks,
Jakob.

From: Antoni Przygienda

inline

Antoni,

Ali,

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 13 May 2014 16:49:29 +0000

Ali, as far I saw, small 'shoulds' never prevented a protocol from doing stuff like this intentionally or unintentionally once enough people took a stab @ it.  In my experience, the price in a spec of  dense,  non-orthogonal encodings like this one is certain amount of verbiage necessary to resolve the collisions or behavior intended on some such.

I concur with Jakob as to clarification of this verbosely as well as the  MAC, MAC/IP  route advertisements.

I spoke up, chiming out now.  Again, I think it's a great spec of high importance, otherwise I wouldn't be thinking through the possible implications of remaining corner-cases  ;-)

--- tony

Cheers,
Ali

Thanks,
Jakob.

From: Antoni Przygienda

inline

Antoni,

Ali,

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 May 2014 17:00:41 +0000

I can understand that if route reflector receives different routes from different speakers, then it can re-order them. But we are talking about different routes from the same speaker (same BGP session and TCP/IP connection).

In your scenario below, the if the MAC is learned via data-plane learning, then the sender has already sent a MAC-only advertisement anyway, so there is no issue.

There can be scenarios in which both MAC/IP and MAC-only routes are advertise for the same MAC and there are scenarios where only MAC/IP routes are advertised. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/IP route. Again, I am not precluding what you are saying. I just don't want to make it a requirement.

Cheers,
Ali

Date: Tuesday, May 13, 2014 9:43 AM

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 13 May 2014 17:13:45 +0000

A route reflector can and frequently does reorder routes from the same speaker.
For example, a version walk of a tree does not walk in version order, it walks in key order.
Fine, you don't want to make it a requirement. Then some words to alert the implementor

Whenever a PE withdraws all MAC advertisement routes with IP address for a particular MAC address, but it still knows the MAC address, it SHOULD advertise one MAC advertisement route without an IP address for that MAC address well in advance of the withdrawals. This is because BGP announcements of different routes are not required to be received in the same order in which they were sent.

Cheers,
Jakob.

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Tuesday, May 13, 2014 10:01 AM
To: Jakob Heitz; [email-masked]
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Tue, 13 May 2014 17:24:51 +0000

Hi Ali and Jakob,

I totally agree with Ali and would not like to add that requirement.
Advertising mac-only + mac/ip or only mac/ip depends on how you learn the IP and how you learn the mac address. Normally both will be advertised if data plane learning is done, since the source mac learning and the snooping of the control packets to get the IP are independent processes. But in hypervisor-based NVE cases, MAC/IP can be learnt at once through control/management plane so in that case a single mac/ip advertisement will be issue.

I would not even add that sentence. In my opinion it is an implementation option to send mac-only or mac-only + mac/ip for the same mac. Afaik there is nothing in the draft against it and again it depends on how you learn both, mac and ip.

My 2 cents.
Jorge

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 13, 2014 at 10:13 AM
To: "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: RE: MAC route with IP

A route reflector can and frequently does reorder routes from the same speaker.
For example, a version walk of a tree does not walk in version order, it walks in key order.
Fine, you don’t want to make it a requirement. Then some words to alert the implementor

Cheers,
Jakob.

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 13 May 2014 17:33:26 +0000

Jorge,

I can see your point. In your case, you never have a case where you know the MAC and not the IP. In that case, it is fine not to advertise a MAC only route, because if you can never lose the MAC/IP binding without also losing the MAC address. Would you agree that my softer sentence does not conflict with your case:

Cheers,
Jakob.

From: Rabadan, Jorge (Jorge) [mailto:[email-masked]]
Sent: Tuesday, May 13, 2014 10:25 AM
To: Jakob Heitz; Ali Sajassi (sajassi); [email-masked]
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Hi Ali and Jakob,

My 2 cents.
Jorge

Cheers,
Jakob.

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 May 2014 17:37:31 +0000

Even if there is reordering by route reflector, then as I said, I don't see an issue here :-) In your example, the receiver sees the withdrawn of the IP/MAC route before receiving the MAC-only route. In that case, the traffic toward that MAC address will get flooding (or dropped if flooding is disabled) till it receives the MAC-only route. However, why does the sender has to wait till it withdraws the IP/MAC advertisement before sending the MAC-only advertisement – e.g., why doesn't the sender send MAC-only advertisement as soon as it learns it.

Again, there are scenarios in which learning is done in data-plane along with ARP suppression. In such scenarios, the sender should send MAC-only route as soon as it learns it and MAC/IP route when it snoops the ARP.  However, there are other scenarios where there is no MAC learning in data-plane. In such scenario, when a VM becomes known, the MAC/IP route is advertised and if the VM goes away, MAC/IP is withdrawn. In such scenarios, we don't want to advertise an extra route (MAC-only route) unnecessarily.

Cheers,
Ali

Date: Tuesday, May 13, 2014 10:13 AM

Cheers,
Jakob.

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Tue, 13 May 2014 17:41:28 +0000

Jakob,

I am not against that ‘softer’ sentence. I simply think it is not even necessary.
But if you convince the authors I am ok.

Thanks.
Jorge

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 13, 2014 at 10:33 AM
To: Jorge Rabadan <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: RE: MAC route with IP

Jorge,

Cheers,
Jakob.

From: Rabadan, Jorge (Jorge) [mailto:[email-masked]]
Sent: Tuesday, May 13, 2014 10:25 AM
To: Jakob Heitz; Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Hi Ali and Jakob,

My 2 cents.
Jorge

Cheers,
Jakob.

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: John E Drake <[email-masked]>
Date: Tue, 13 May 2014 17:41:38 +0000

Jorge,

I completely agree.

Yours Irrespectively,

John

From: L2vpn [mailto:[email-masked]] On Behalf Of Rabadan, Jorge (Jorge)
Sent: Tuesday, May 13, 2014 10:25 AM
To: Jakob Heitz; Ali Sajassi (sajassi); [email-masked]
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Hi Ali and Jakob,

My 2 cents.
Jorge

Cheers,
Jakob.

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: John E Drake <[email-masked]>
Date: Tue, 13 May 2014 17:44:35 +0000

Ali,

As both Jorge and you have pointed out, there may indeed be cases for which there should not be a MAC only route.

Yours Irrespectively,

John

From: L2vpn [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, May 13, 2014 10:38 AM
To: Jakob Heitz; [email-masked]
Cc: Antoni Przygienda
Subject: Re: MAC route with IP

Even if there is reordering by route reflector, then as I said, I don't see an issue here :-) In your example, the receiver sees the withdrawn of the IP/MAC route before receiving the MAC-only route. In that case, the traffic toward that MAC address will get flooding (or dropped if flooding is disabled) till it receives the MAC-only route. However, why does the sender has to wait till it withdraws the IP/MAC advertisement before sending the MAC-only advertisement - e.g., why doesn't the sender send MAC-only advertisement as soon as it learns it.

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 May 2014 17:55:02 +0000

Yes, although my email and Jorge's emails crossed each others, we are both saying exactly the same thing.

That's why I think the existing text is sufficient and we don't need to add any thing more because both of the scenarios I mentioned below can happen and the existing text covers them both.

Cheers,
Ali

From: John E Drake <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 13, 2014 10:44 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>, Jakob Heitz <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: RE: MAC route with IP

Ali,

Yours Irrespectively,

John

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Tue, 13 May 2014 18:00:05 +0000

Fully agree.

Thx
Jorge

From: "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 13, 2014 at 10:55 AM
To: John E Drake <[email-masked]<mailto:[email-masked]>>, Jakob Heitz <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: Re: MAC route with IP

Cheers,
Ali

Ali,

Yours Irrespectively,

John

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Aldrin Isaac <[email-masked]>
Date: Tue, 13 May 2014 14:14:32 -0400

Would it be worthwhile to mention that MAC/IP routes should not be used as
a proxy for MAC-only route?

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <[email-masked]> wrote:

>  That's why I think the existing text is sufficient and we don't need to
> add any thing more because both of the scenarios I mentioned below can
> happen and the existing text covers them both.
>
>  Cheers,
> Ali
>
>
>
>   From: John E Drake <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
> To: Cisco Employee <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>,
> Jakob Heitz <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>,
> "[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> Cc: Antoni Przygienda <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
> As both Jorge and you have pointed out, there may indeed be cases for
> which there should not be a MAC only route.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
> *From:* L2vpn [mailto:[email-masked]] *On Behalf Of *Ali Sajassi
> (sajassi)
> *Sent:* Tuesday, May 13, 2014 10:38 AM
> *To:* Jakob Heitz; [email-masked]
> *Cc:* Antoni Przygienda
> *Subject:* Re: MAC route with IP
>
>
>
>
>
> Even if there is reordering by route reflector, then as I said, I don't
> see an issue here :-) In your example, the receiver sees the withdrawn of
> the IP/MAC route before receiving the MAC-only route. In that case, the
> traffic toward that MAC address will get flooding (or dropped if flooding
> is disabled) till it receives the MAC-only route. However, why does the
> sender has to wait till it withdraws the IP/MAC advertisement before
> sending the MAC-only advertisement – e.g., why doesn't the sender send
> MAC-only advertisement as soon as it learns it.
>
>
>
> Again, there are scenarios in which learning is done in data-plane along
> with ARP suppression. In such scenarios, the sender should send MAC-only
> route as soon as it learns it and MAC/IP route when it snoops the ARP.
>  However, there are other scenarios where there is no MAC learning in
> data-plane. In such scenario, when a VM becomes known, the MAC/IP route is
> advertised and if the VM goes away, MAC/IP is withdrawn. In such scenarios,
> we don't want to advertise an extra route (MAC-only route) unnecessarily.
>
>
>
> Cheers,
>
> Ali
>
>
>
> *From: *Jakob Heitz <[email-masked]>
> *Date: *Tuesday, May 13, 2014 10:13 AM
> *To: *Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]
> >
> *Cc: *Antoni Przygienda <[email-masked]>
> *Subject: *RE: MAC route with IP
>
>
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 May 2014 18:32:31 +0000

Hi Aldrin,

I believe the application of MAC/IP route in section 10 is clear. However, if you think we can make further clarification, please suggest the text. We need to make sure the functionality that we specify is clearly described and explained. We don't need to describe/mention the functionality that is not used/needed.

Thanks,
Ali

From: Aldrin Isaac <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 13, 2014 11:14 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <[email-masked]<mailto:[email-masked]>>, Jakob Heitz <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: Re: MAC route with IP

Would it be worthwhile to mention that MAC/IP routes should not be used as a proxy for MAC-only route?

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
Ali

From: John E Drake <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Date: Tuesday, May 13, 2014 10:44 AM
To: Cisco Employee <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, Jakob Heitz <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>" <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Cc: Antoni Przygienda <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Subject: RE: MAC route with IP

Ali,

Yours Irrespectively,

John

Cheers,

Ali

From: Jakob Heitz <[email-masked]>
Date: Tuesday, May 13, 2014 10:13 AM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Antoni Przygienda <[email-masked]>
Subject: RE: MAC route with IP

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 13 May 2014 23:26:16 +0000

Thanks Ali.
I recognize the case where a MAC only route is not needed.
My text does not preclude that.
My text is advisory to avoid the small time of flooding in an unlikely scenario.
I do recognize that it is not necessary to ensure correctness of the draft.
With that:

I have studied the draft and consider it ready for publication.

Thanks,
Jakob.

Cheers,
Ali

Thanks,
Jakob.

Jakob,

Cheers,
Ali

Thanks,
Jakob.

Jakob, Antoni:

Cheers,
Ali

Cheers,
Jakob.

Cheers,
Jakob.

Hi Jakob,

Cheers,
Ali

We have another issue

   withdrawn.

Thanks,
Jakob.

---

From: Aldrin Isaac <[email-masked]>
Date: Tue, 13 May 2014 23:02:14 -0400

How about:

"Note that a MAC-only route can be advertised along with MAC/IP routes for use
cases where an active MAC must remain reachable when all IP's become
disassociated with that MAC."

On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <[email-masked]> wrote:

>  Hi Aldrin,
>
>  I believe the application of MAC/IP route in section 10 is clear.
> However, if you think we can make further clarification, please suggest the
> text. We need to make sure the functionality that we specify is clearly
> described and explained. We don't need to describe/mention the
> functionality that is not used/needed.
>
>  Thanks,
> Ali
>
>   From: Aldrin Isaac <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
> To: Cisco Employee <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
> Cc: John E Drake <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>,
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, Antoni
> Przygienda <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
>   From: John E Drake <[email-masked]>
> To: Cisco Employee <[email-masked]>, Jakob Heitz <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *From:* L2vpn [mailto:[email-masked]] *On Behalf Of * Ali Sajassi
> (sajassi)
> *Date: *

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 14 May 2014 06:22:39 +0000

Hi Aldrin,

How about the following:

"Note that a MAC-only route can be advertised along with but independent from MAC/IP route for scenarios where the MAC learning over access network/node is done in data-plane and independent from ARP snooping that generates MAC/IP route. In scenarios where host MAC/IP is learned via management or control plane, then the sender PE may only generates and advertises MAC/IP route."

Cheers,
Ali

Date: Tuesday, May 13, 2014 8:02 PM

How about:

"Note that a MAC-only route can be advertised along with MAC/IP routes for use cases where an active MAC must remain reachable when all IP's become disassociated with that MAC."

Thanks,
Ali

From: Aldrin Isaac <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Date: Tuesday, May 13, 2014 11:14 AM
To: Cisco Employee <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Cc: John E Drake <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, Jakob Heitz <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>" <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, Antoni Przygienda <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Subject: Re: MAC route with IP

Cheers,
Ali

To: Cisco Employee <[email-masked]>, Jakob Heitz <[email-masked]>, "[email-masked]" <[email-masked]>

Ali,

Yours Irrespectively,

John

Cheers,

Ali

Date:

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 14 May 2014 07:09:04 +0000

"Note that a MAC-only route can be advertised along with but independently of a MAC/IP route in scenarios where the MAC learning over the access network is done in the data-plane and independently of ARP snooping that generates the MAC/IP route. This ensures that if the ARP entry times out and causes the MAC/IP to be withdrawn, then the MAC information will not be lost. In scenarios where the host MAC/IP is learned via the management or control planes, the sender PE may advertise only the MAC/IP route."

--
Jakob Heitz.

On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Aldrin,

How about the following:

Cheers,
Ali

How about:

Thanks,
Ali

Cheers,
Ali

Ali,

Yours Irrespectively,

John

Cheers,

Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 14 May 2014 14:10:02 +0000

Hi Jakob,

Changed your sentence to: "In such scenarios when the ARP entry times out and causes the MAC/IP to be withdrawn, then the MAC information will not be lost."

Cheers,
Ali

From: Jakob Heitz <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 14, 2014 12:09 AM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: Aldrin Isaac <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: Re: MAC route with IP

--
Jakob Heitz.

Hi Aldrin,

How about the following:

Cheers,
Ali

How about:

Thanks,
Ali

Cheers,
Ali

Ali,

Yours Irrespectively,

John

Cheers,

Ali

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 14 May 2014 15:45:18 +0000

Looks good. Thanks.

--
Jakob Heitz.

On May 14, 2014, at 7:10 AM, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

Cheers,
Ali

--
Jakob Heitz.

Hi Aldrin,

How about the following:

Cheers,
Ali

How about:

Thanks,
Ali

Cheers,
Ali

Ali,

Yours Irrespectively,

John

Cheers,

Ali

---

From: Aldrin Isaac <[email-masked]>
Date: Wed, 14 May 2014 12:07:48 -0400

+1  :)

On Wednesday, May 14, 2014, Jakob Heitz <[email-masked]> wrote:

>  Looks good. Thanks.
>
> --
> Jakob Heitz.
>
>
> On May 14, 2014, at 7:10 AM, "Ali Sajassi (sajassi)" <[email-masked]>
> wrote:
>
>
>  Hi Jakob,
>
>  Changed your sentence to: "In such scenarios when the ARP entry times
> out and causes the MAC/IP to be withdrawn, then the MAC information will
> not be lost."
>
>  Cheers,
> Ali
>
> To: Cisco Employee <[email-masked]>
> Cc: Aldrin Isaac <[email-masked]>, John E Drake <
> [email-masked]>, "[email-masked]" <[email-masked]>, Antoni Przygienda
> <[email-masked]>
>   "Note that a MAC-only route can be advertised along with but
> independently of a MAC/IP route in scenarios where the MAC learning over
> the access network is done in the data-plane and independently of ARP
> snooping that generates the MAC/IP route. This ensures that if the ARP
> entry times out and causes the MAC/IP to be withdrawn, then the MAC
> information will not be lost. In scenarios where the host MAC/IP is learned
> via the management or control planes, the sender PE may advertise only the
> MAC/IP route."
>
> --
> Jakob Heitz.
>
>
> On May 13, 2014, at 11:22 PM, "Ali Sajassi (sajassi)" <[email-masked]>
> wrote:
>
>
>  Hi Aldrin,
>
>  How about the following:
>
>  "Note that a MAC-only route can be advertised along with but independent
> from MAC/IP route for scenarios where the MAC learning over access
> network/node is done in data-plane and independent from ARP snooping that
> generates MAC/IP route. In scenarios where host MAC/IP is learned via
> management or control plane, then the sender PE may only generates and
> advertises MAC/IP route."
>
>  Cheers,
> Ali
>
>   From: Aldrin Isaac <[email-masked]>
> To: Cisco Employee <[email-masked]>
> Cc: John E Drake <[email-masked]>, Jakob Heitz <
> [email-masked]>, "[email-masked]" <[email-masked]>, Antoni
> Przygienda <[email-masked]>

---

From: Aldrin Isaac <[email-masked]>
Date: Wed, 14 May 2014 12:11:37 -0400

Btw should "in such scenerarios when" be "in such scenarios where" ?

On Wednesday, May 14, 2014, Ali Sajassi (sajassi) <[email-masked]> wrote:

>   From: Jakob Heitz <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
> Cc: Aldrin Isaac <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>,
> John E Drake <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>,
>  "Note that a MAC-only route can be advertised along with MAC/IP
> routes for use cases where an active MAC must remain reachable when all
> IP's become disassociated with that MAC."
>
>  Would it be worthwhile to mention that MAC/IP routes should no
>
>

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 14 May 2014 17:19:55 +0000

I would be more inclined to put a comma after when:
"In such scenarios, when the ARP entry times out and causes the MAC/IP to be withdrawn, then the MAC information will not be lost."

Cheers,
Jakob.

From: Aldrin Isaac [mailto:[email-masked]]
Sent: Wednesday, May 14, 2014 9:12 AM
To: Ali Sajassi (sajassi)
Cc: Jakob Heitz; John E Drake; [email-masked]; Antoni Przygienda
Subject: Re: MAC route with IP

On Wednesday, May 14, 2014, Ali Sajassi (sajassi) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

Cheers,
Ali

From: Jakob Heitz <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Date: Wednesday, May 14, 2014 12:09 AM
To: Cisco Employee <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Cc: Aldrin Isaac <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, John E Drake <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>" <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, Antoni Przygienda <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Subject: Re: MAC route with IP

--
Jakob Heitz.

Hi Aldrin,

How about the following:

Cheers,
Ali

How about:

Thanks,
Ali

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 14 May 2014 19:32:58 +0000

Isn’t it same as “Sticky MAC” or “Persistent MAC Learning”?

Linda

From: L2vpn [mailto:[email-masked]] On Behalf Of Jakob Heitz
Sent: Wednesday, May 14, 2014 12:20 PM
To: Aldrin Isaac; Ali Sajassi (sajassi)
Cc: [email-masked]; Antoni Przygienda
Subject: RE: MAC route with IP

Cheers,
Jakob.

Cc: Jakob Heitz; John E Drake; [email-masked]<mailto:[email-masked]>; Antoni Przygienda

Hi Jakob,

Cheers,
Ali

--
Jakob Heitz.

Hi Aldrin,

How about the following:

Cheers,
Ali

How about:

Thanks,
Ali