Hello Bruno and spring list experts, jumping late into the discussion (sorry).
I would see any kind of preference list to handle a conflict to be an somewhat arbitrary decision. That is okay for a particular network (assuming the network operator had a word or two about the rules) but I don't consider this a good idea for a standard to reflect specific designs or operational/troubleshooting procedures. E.g. who is saying that IPv6 should be preferred over IPv4? What when the operator's workhorse is still IPv4 traffic and s/he would prefer to sacrifice IPv6 to keep IPv4 running? In reality, don't we expect the rule ... "Local configuration conflicts can be prevented before they are advertised" ... to cover the large amount of mistakes? Then the basic "ignore" policy would cover the few cases where things went really bad. We seem to spend a lot of time and energy on solving a problem that should be rare (with the quoted rule above). Basically what I propose is to keep it simple. At least start simple. _If_ network operators find during operation that the basic don't-advertise/ignore rule is insufficient then we can still increase the complexity of the conflict handling procedure (and add a config knob to select the new procedure). Regards, Marc On Thu, 28 Jul 2016 12:36:01 +0000, [email protected] wrote: > Hi Les, all > > As an individual contributor. > > As a network operator, I have a slight preference for the older preference > rule, and more specifically for the following preference rule: > 1) PFX source wins over SRMS source > 2) Between redundant SRMS, operator defined preference (aka weight) > > Note however, that for me, this is a lighter preference compared to the > choice of the policy. Besides, my above preference assumes that the policy > "Per FEC/Ignore overlap only" be selected. If "Quarantine" were selected, I > would have a strong preference for the revised preference rule (Larger > range wins) in order to limit the consequences on the network availability. > > Regarding 1, > I would assume that before the conflicting advertisement, the network was > running fine. i.e. conflict entries is not the nominal behavior in the > network, and conflict are detected and reported to the network operator for > correction. (e.g. via the yang model, syslog, error message on the terminal > (hence in particular the one configuring the conflicting entry...). > With such assumption, the conflict is likely the result of a > misconfiguration on one node. Preferring PFX source over SRMS give > preference to diversity/the majority of the nodes rather than the > individual (mapping server). In this assumption where a single node is > misconfigured, preference many advertisement over a single one, maximize > the number of valid advertisement kept. I agree that this is dependent on > the assumption, and another scenario could be that one had mis-program the > script configuring the prefix SID on N routers, which would results in N > simultaneous misconfigurations. > Additionally, following the principle that the one speaking for himself is > probably the best source, I'd be inclined to trust the originator of the IP > prefix, as the reference for the SID to be used. > > Regarding 2, > Some network operation people have expressed a need to control which > advertisement is preferred, especially to control SID renumbering (e.g. in > case of network merge). cf Stéphane email. Putting this preference lower > (e.g. after preferring the larger range) would somewhat defeat the goal or > make it less predictable for people. > > Regards, > --Bruno > >> -----Original Message----- >> From: spring [mailto:[email protected]] On Behalf Of Martin Horneffer >> Sent: Friday, July 22, 2016 10:59 AM >> To: Les Ginsberg (ginsberg); [email protected] >> Cc: Horneffer, Martin >> Subject: [spring] draft-ietf-spring-conflict-resolution - Preference Rule >> >> Hi Les, >> >> this topic, and this document is in my eyes a very important one. Thanks >> a lot for writing and promoting it! >> >> During the Berlin WG session you proposed a new preference rule which >> would make the policy choice easier. You asked for a discussion on the >> list - more on your slides rather than the existing draft document. >> >> As an operator, and as an individual that has insight in more than just >> one or two IP/MPLS carrier networks, that has the main engineering >> responsibility for a rather large backbone, and that stays in actual >> contact with the operational staff and security authorities, I strongly >> ask you: PLEASE DO NOT CHANGE THE PREFERENCE RULE! >> >> The first two elements of the preference rule are, in my eyes, the most >> important ones of the whole document and must not be changed or dropped! >> 1) PFX source wins over SRMS soucre >> 2) Smaller range wins >> >> Why is this so important? >> >> I don't care so much about the _amount_ of traffic that would be >> affected by a conflict. No amount of traffic lost due to a network >> design or configuration error is permissible. But I do care about the >> overall _robustness_ and _security_ of the network. >> >> Of course - in terms of security a first approximation would say that >> segment routing plays within the IGP only, and that the IGP needs to be >> trusted anyways. It must be secured against the outside. While this is >> true, I nevertheless would like to differentiate a bit more. >> >> For the sake of robustness, and possibly also for security, I would like >> to apply the following guidelines: >> a) Effects of local misconfiguration should be as local as possible. >> b) The more reliable and controllable source should win over a less >> reliable or controllable one. >> >> As I see it, both guidelines lead to a clear preference of PFX sources >> over SRMS sources. Also the preference for smaller ranges seems to fit. >> >> Please do consider environments where more and more formely separate >> IP/MPLS networks get merged into a single IGP domain. I am seeing this a >> lot since a couple of years - several times within DT, but also at other >> carriers. Sometimes this is done as a complete merge e.g. into a single >> IS-IS area, sometimes different areas are used, and sometimes seperate >> IGP instances are maintained but connected. While redistributing from >> one IGP area or instance to the other you can do more or less filtering, >> but it definitely is being done. Thus, even within the IGP filters and >> policies are being applied - be it for the sake of security or >> scalability. While there are well-known mechanisms and tools to filter >> and control prefix redistribution, I am not so sure about SRMS. >> >> >> I'm going to also write my opinion about the policy selection, but >> keeping the preference rule really is my main concern. >> >> >> BR, >> Martin >> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring > > _________________________________________________________________________________________________________________________ > > 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. > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
