> 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
