Re: [Isis-wg] Conflicting MS entries

["Stefano Previdi (sprevidi)" <[e-mail]>]

<removing the long recipient list and adding isis-wg>
Background information about this issue is on the original email here below.


Hi Stephane,

On Jun 17, 2015, at 10:42 AM, <[e-mail]> wrote:
> Hi Stefano,
> 
> As discussed in Dallas, there may be no ideal option but let's try to find one which may try to preserve the transport service. So I'm not in favor of option 1.
> There may be three kinds of overlap :
> 1) prefix overlap with different indexes, example :
> 	192.0.2.0/32 range 10 index 100
> 	192.0.2.5/32 range 1 index 2000
> 	192.0.2.5/32 range 2 index 3000
> 	In this case 192.0.2.5/32 is associated with three different indexes
> 
> 2) index overlap, example :
> 	192.0.2.0/32 range 10 index 100
> 	198.15.0.0/32 range 100 index 100
> 	In this case, different prefixes will use the same index.
> 
> 3) overlap between binding TLV and prefix entry
> 	192.0.2.0/32 range 10 index 100 learned from MS
> 	192.0.2.5/32 index 200 learned from TLV135
> 	In this case 192.0.2.5/32 is associated with two different indexes learned by two different ways


very good points above and that illustrate even better the complexity of the scheme we would need to define in order to cope with all possible cases.


> 2) must be solved as we manage conflicting SIDs associated with connected prefixes. It's a similar case, two different prefixes having the same SID.


yes, this is the easy one. Again, no real solution here but as you pointed out, you may still want to preserve part of the reachability. 

> 
> 1)3) If we think about tiebreaker, I'm not sure that preferring local MS entries over remote MS entries is a good idea as it may lead to inconsistencies while the target may be to have everyone taking the same decision.  In contrary, I would make prefer prefix SID mappings over MS entries.


yes, I agree. The point was what to prefer between a received MS entry vs. a locally defined MS entry. But as you aid, if we prefer anything "local" we can't rely on network-wide consistent behavior.

s.


> To compare MS entries, it may be possible to consider something like lowest range and then lowest index for example.
> 
> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:[e-mail]] 
> Sent: Tuesday, June 16, 2015 19:15
> To: Clarence Filsfils (cfilsfil); Ahmed Bashandy (bashandy); Hannes Gredler; LITKOWSKI Stephane SCE/IBNF; DECRAENE Bruno IMT/OLN; Jeff Tantsura; Les Ginsberg (ginsberg); Wim (Wim) Henderickx; Steven Luong (sluong)
> Subject: Conflicting MS entries
> 
> Co-authors and Contributors,
> 
> I'd like to close on the conflicting MS entries issues. 
> 
> The issue is related to what a receiver should do when receiving to or more conflicting MS mappings.
> 
> So far we agreed that there's no way we can determine which one is good or bad and therefore whatever action we mandate it will create disruption. The choices are:
> 
> 1. ignore all conflicting entries
> 2. select one of the conflicting entry based on whatever breaking tie algo.
> 
> Obviously, option1 is the easiest knowing that no other option would allow to fix the conflict anyway.
> Option2 may be appealing but in such case we would have to consider all corner cases such as:
> . what about a conflict between locally configured mapping entry and received ones ?
> . what about conflicting entries received by the same router ? which one to select ?
> 
> I think it is preferable to ignore all conflicting entries and log and error message. We discussed about this in Dallas but despite the agreement on the absence of a cure we decided, at that time, to let the operators to give feedback on the proposal.
> 
> Is there anything that has changed ?
> 
> Also, let me know if you'd prefer to bring the issue to the mailing list before reaching agreement among co-authors.
> 
> Thanks.
> s.
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>