Hi Les > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > Sent: Thursday, > June 25, 2015 4:32 PM > > Bruno - > > I am thinking that the behavior you prefer below requires further > specification.
Sure. I'm all for the specification. Let me just recap my proposal: - SRGB descriptor _are_ already ordered - I propose to consider the SRGB descriptors in this order, accept all valid ones until we find some in errors. If which cases stop considering further descriptors as they are at risk. > Consider an example. We receive the following set of SRGB ranges: > > 20000-22000 > 21000-24000 > 26000-28000 > > In such a case no one would consider using any of the ranges because the first > two overlap - and using the third range (which does NOT overlap) is likely to > be wrong because indices less than 4000 seem like they should be into one of > the first two ranges - but we can't really be sure because we don't know > which of the three ranges was misconfigured. So we agree on this one. > Now, here is a second case: > > 26000-28000 > 20000-22000 > 21000-24000 > > Here, again, we don't know which of the three ranges is misconfigured - but > because it is the first range which does not conflict you want us to assume > that > it must be correct. We actually have no more reason to believe it is correct > than we did in the first case - but because it is the first range you propose > that > we trust it. I propose to accept the SRGB descriptors until there is a problematic one. There is no issue with the first SRGB ranges. There is no reason to believe that the originator is not capable of doing the sum (SRGB+index) and program the result in its MPLS ILM (Incoming Label Map). > Now, the second case "might" be less ambiguous if we had some history - for > example, suppose the same router had previously advertised: > > 26000-28000 > 20000-22000 > > Then it advertised the third range (in conflict w second range) shown above. > With this history we "might" feel more strongly that the misconfiguration was > associated w adding the third range and so it is safe to use the first range. > But > in the absence of history we really don't know which of the ranges should be > considered valid - we are just hoping that the config error (or implementation > bug) is confined. > > Now, if you want to bring "history" into the specification, things become less > predictable I have never talked about bringing history in the picture. Let's discuss my proposition, rather than building something different to better disregard it. > because it is possible that a recently booted router won't have > the history - and so now all routers won't agree on what should be used and > what should not. > > This is an example of how complex things can get when we try to define rules > about how to deal with a set of information which is in error. This is why, > though I appreciate your desire to try to preserve what you hope is usable, > taking a simpler approach (ignore) is appealing. _You_ changed the proposition to make it complex by introducing history. Again, let's discuss the proposition on the table. In term of complexity: In both propositions you need to - parse SRGB descriptor, presumably in order. - detect inconsistency between SRGB descriptors. - log the error a) With my proposition, you stop the SRGB parsing here and do nothing else. b) With your proposition, you need to roll back and remove previous SRGB descriptor. It's not clear to me why "a" (i.e. do nothing) is more complex than "b" (roll back). Now, it would be good to also discuss the impact on the customer traffic of both approaches: - if the node is considered non SRGB capable, all traffic for all FEC crossing that node is dropped. In a MPLS VPN network where all traffic is MPLS, this is a big impact - if we only disregard the problematic SRGB descriptors, we save part of the traffic. How much of the traffic is purely hypothesis dependent. However as the spec recommend (SHOULD) to add new SRGB descriptor at the end, typically all existing traffic would be unaffected. So in summary, using the valid SRGB descriptors: - brings no issue - is equally simple - provides a significant protection of existing traffic. Indeed, some existing implementation may need to be touched, but the change does not bring interoperability issue (compared to the previous one on this subject, at least for IS-IS) /Bruno > Les > > > -----Original Message----- > > From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of > > bruno.decra...@orange.com > > Sent: Thursday, June 25, 2015 6:58 AM > > To: Stefano Previdi (sprevidi); isis...@ietf.org list > > Cc: ospf@ietf.org > > Subject: Re: [OSPF] How to handle multiple overlapping SRGB ranges > > > > > From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Stefano > > > Previdi (sprevidi) > > > > > > All, > > > > > > there's an open question that requires the wg to agree > > > > > > The issue here is related to SRGB ranges advertised within the > > > SR-Cap > > SubTLV. > > > > > > The question is: what a receiving router should do when receiving > > > SRGB ranges that overlaps ? > > > > Presumably, the question is equally applicable to OSPF, so I'm adding > > the ospf WG in the discussion. > > > > > > > Knowing that the spec mandates a single SR-Cap SubTLV, the overlap > > > may happen only within the same SR-Cap subTLV and therefore it is > > > clearly a local misconfiguration or an implementation bug in the > > > router originating the SR- Cap. > > > > > > Personally, I would recommend to ignore the whole SRGB (not only the > > > overlapping ranges) from the faulty router. Ignoring only the > > > overlapping ranges would not work since the whole index space is > > > affected > > anyway. > > > > Personally, I would recommend ignoring the overlapping SRGB Descriptor > > and the subsequent ones. But I'd rather keep the SRGB descriptors > > which are before (the overlaps) as they do not pose a problem. Keeping > > them preserve the forwarding of the global Segments using them. This > > seems inline with the IETF Robustness Principle > > https://tools.ietf.org/html/rfc1122#section-1.2.2 > > > > " 1.2.2 Robustness Principle > > > > At every layer of the protocols, there is a general rule whose > > application can lead to enormous benefits in robustness and > > interoperability [IP:1]: > > > > "Be liberal in what you accept, and > > conservative in what you send" > > > > Software should be written to deal with every conceivable > > error, no matter how unlikely; sooner or later a packet will > > come in with that particular combination of errors and > > attributes, and unless the software is prepared, chaos can > > ensue." > > [...] > > "host software should be prepared, not > > just to survive other misbehaving hosts, but also to cooperate > > to limit the amount of disruption such hosts can cause to the > > shared communication facility." > > > > In particular "cooperate to limit the amount of disruption" > > > > Thanks > > /Bruno > > > > > There are different opinions on how the receiving router should behave. > > > Ideally, we should converge towards a single solution so feel free > > > to > > comment. > > > > > > Thanks. > > > s. > > > > > > _______________________________________________ > > > Isis-wg mailing list > > > isis...@ietf.org > > > https://www.ietf.org/mailman/listinfo/isis-wg > > > > __________________________________________________________ > > __________________________________________________________ > > _____ > > > > 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. > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf _________________________________________________________________________________________________________________________ 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. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
