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
