Re: MAC route with IP

["Ali Sajassi (sajassi)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, May 13, 2014 9:37 AM
To: Antoni Przygienda <[e-mail]<mailto:[e-mail]>>, Cisco Employee <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: MAC route with IP

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; [e-mail]<mailto:[e-mail]>
Subject: RE: MAC route with IP

inline

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

Antoni,

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

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).

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.


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 ?

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.

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 ?

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).