Hi Stéphane, Many thanks for contributing on this subject and for your comments.
Please see inline [Bruno] Les, there is a specific question for you at the penultimate comment. I'll send an updated text and diff in a few days, after considering comments from currently unread emails. Bruno > -----Original Message----- > From: LITKOWSKI Stephane SCE/OINIS > Sent: Monday, January 04, 2016 9:41 AM > To: DECRAENE Bruno IMT/OLN; [email protected]; Les Ginsberg (ginsberg) > Subject: RE: draft-ginsberg-spring-conflict-resolution > > Hi Bruno, > > And best wishes all for this new year. > > > It seems that posting your txt back as attachment to the list does not work > so I > will put my comments on the text directly in the email : [Bruno] sorry for the inconvenience. To avoid commenting twice, you could have copy / past the .txt attachment into the email body. > - In §2.2 : you keep the statement "The following ranges are used:" empty, > may be it would be better to change with something like : "None of the ranges > are used in this case" [Bruno] This is already spelled out lines above "In case of conflicts, all the ranges advertised are invalidated and dropped." But I see what you mean. On the other hand, the goal was to have a short summary to allow comparison between options. Currently I've changed to "The following ranges are used: <none>" But any other option is welcomed > - §2.6 : It should be mentioned that this kind of behavior should never happen > because the sender > must have local configuration procedures to avoid this kind of behavior. Added: These SRGB ranges are advertised by a single node. As per [SR-IS-IS], a node MUST not advertise overlapping SRGB ranges. Hence a SRGB range conflict means a bug in the implementation of the originator. > But in case there is something going wrong and such advertisement is > received, routers must have a consistent behavior. > IMO, as the local implementation must avoid this kind of advertisement (and I > think we need to state this somewhere), [Bruno] I agree with you. I think this should be mentioned in §2.7 "Discussion" rather than in §2.6. I propose to add: "These SRGB ranges are advertised by a single node. As per [SR-IS-IS], a node MUST not advertise overlapping SRGB ranges. Hence a SRGB range conflict means a bug in the implementation of the originator. However, bugs happen and we need a consistent error handling behaviour across the network to minimize mis-routing and to allow ingress to know the state of the network and act upon (e.g. reroute around the bug)" > drop all > sounds the best option because as this might be a bug, nothing says that the > forwarding is correctly setup on the node sending the bad advertisement. [Bruno] At this point in time, I would rather write down the pro&con of each option, in order to allow technical discussion, refinement and hopefully drive the discussion toward consensus. Personally, as of today, I would favor either "Drop all" or "Drop from conflict". The latter have the nice property that, assuming that the network was running correctly before, the issue is with the added SRGB range which may be expected to be added to allow for future growth. i.e. not currently used. So this seems overkill to drop all traffic, for a SRGB range which has been added and is not even used by global SIDs. > - §3. : IGP LSDB may be too restrictive, as depending of the label management > implementation, there might be cross protocol conflicts of SIDs. [Bruno] Agreed. But: - this is a text from Les, I'll leave the resolution to Les - I'd rather avoid making the issue more complex, while we still can't agree on conflict resolution within a protocol. > > - §3.2.1 : > [SLI] Maybe we should mention that this kind of conflict has a "limited" > impact. > On the LSR, we have more LFIB consumption but no traffic impact, as we are > creating > multiple parallel LSPs towards the same destination. > At the iLSR side, there might be some churn in the FIB (IP to MPLS entry) as > it > will have > to choose one or the other advertisement in order to program the entry. [Bruno] Agreed. Good point thanks. Added in 3.2.1 (1 prefix, multiple SIDs): "The consequences of this conflict is that multiple MPLS FIB entries would be programmed for a single IP Prefix. This has no impact on the traffic but use more MPLS FIB entries, which may or not be problematic for the network equipments." > - §3.2.2 : > [SLI] As previous comment, we may need to mention the impact of such > conflict : inconsistent routing (even possible loops) > if there is disagreement between routers (LSRs). [Bruno] Agreed. Good point thanks. Added in 3.2.2 (1 SID, multiple prefixes): " The consequences of this conflict is that in the absence of conflict resolution two IP prefixes would be forwarded to the same destination. If they are part of the same FEC (Forwarding Equivalent Class), this is not an issue. Otherwise, this leads to mis-routing of a prefix to a wrong destination. In a VPN network, this may lead to VPN breach which is very problematic (even if the breach would be unidirectional only). In case of inconsistent conflict resolution across nodes, this may lead to persistent forwarding loops." > - §3.3 : > [SLI] We must mention, that traffic is dropped for the destination affected by > the conflict. > So if a new advertisement is received after a while leading to a conflict, > traffic > will be blackholed > for the affected destination [Bruno] From an editorial standpoint, I have chosen to describe the options from a specification standpoint. So that those sections should be non controvertials. Discussion is done in §3.6 "Discussion". >From a technical standpoint, I agree with you and this is discussed in 3.6.2 >'Network operation" >which is IMO not a good option. [Bruno] Personally, I agree with you. I would even say that this is not acceptable that a single typo in a MS advertisement shut down half of the network. But at this point in the document and discussion, I'd rather stick to facts and remove opinions. > - §3.4 : > [SLI] What happens if BGP sends the same SID ? [Bruno] At this point, I'm focusing to conflict within a single protocol. Given the disagreements, I'd rather reduce the scope to simplify. But I agree with you that this is a valid question. > > -§3.5 : > [SLI] Maybe we need to remind that we already have a tiebreaking rule > between MS entries and Prefix SIDs : > "For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV > and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the > Prefix-SID advertised within the Prefix TLV MUST be preferred while > the MS entry MUST be ignored." > > [SLI] Giving a preference to MS entries may be a very good idea from > an operational point of view, especially if someone wants to migrate > mappings from one range to another for example. This discussion is out of > scope but we may need to think about it. [Bruno] Excellent point. But as the resolutions rules proposed in draft-ginsberg-spring-conflict-resolution do not seem achieve the above goal, I had assume that this current text from draft-ietf-isis-segment-routing-extensions would be removed and replaced by the resolutions rules described in draft-ginsberg-spring-conflict-resolution. Les, could you please clarify this point? > - there are multiple small typo issues in SRGB examples : e.g. Range 3: (500, > 5990 <=> Range 3: (500, 599) ; Range 1: (100, 199] <=> Range 1: (100, 199) [Bruno] Thanks. Fixed. (at least I'm consistent in my typos ;-) (which is expected when copy/pasting) ) > > -----Original Message----- > From: spring [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Thursday, December 17, 2015 18:27 > To: [email protected]; Les Ginsberg (ginsberg) > Subject: [spring] draft-ginsberg-spring-conflict-resolution > > Hi Les, authors, WG > > As an individual contributor, please find below some more detailed comments > and considerations on the draft. > > Following the "please send text" request expressed during the meeting, > please find enclosed some proposed text. (xml, txt, diff versus public > version). > > I wished I had sent this before, but writing the text took longer than > expected. > BTW I still not happy with my text, but hopefully current text (or at least > the > table of content) should be enough to give an idea on the direction I have in > mind. > > Thanks, > Regards, > Bruno > > __ > As previous expressed on the mailing list and during the meeting, I'm > especially concerned with Mapping Server advertisement where a single > typo/bug can conflict with many/all SIDs in the network. In this case, I don't > think that dropping all traffic to those SIDs is a desirable option. > One option is to prefer individual advertisement (prefix SID) over general > ones (Mapping Server). i.e. more specific wins. Note that this is the approach > currently taken by the IS-IS draft: > " For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV > and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the > Prefix-SID advertised within the Prefix TLV MUST be preferred while > the MS entry MUST be ignored." > > We can probably assume that this is already implemented (by compliant > implementations), so I'm not sure to see the value of changing existing > implementations if this is to get a more disruptive result for the network. > __ > Regarding SID conflict, the current draft proposes to drop all conflicting > information. > Looking at the big picture, this means: the more (Mapping Server) > redundancy, the more risk of conflict, the less availability. > This is probably not the property that we are looking for. > __ > > I support the comment to consider the error handling work "recently" done in > the IDR WG. IMHO, WG and authors did a good work on such a difficult subject > (just like for SID conflicts, at the beginning opinions were diverse, and > everyone had good reasons). > I'm not sure how much reading the end result (RFC 7606) helps in > understanding all the trade-off considered during the work. Reading the > operational requirements, given that the IGP infrastructure is probably even > more important than BGP for network operators/clients/traffic, it may be > worthwhile to read BGP error handling operation requirements ( > https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-07 > ) Discussion with the people involved may help. FYI, as for me, the point I > learnt are: > - when we detect an error on the receiving side, there is a bug. In general, > it's > difficult to know whether the bug is on the sending side or the receiving > side. > Clearly, for the receiving side, the first reaction is to blame the sending > side. > For each error, it's useful to consider both options (i.e. error may be on > my/receiving side). And even if the error is on the sending side, the receiver > may run the same implementation (so "sender is too buggy to live" may apply > to your own implementation i.e. the receiving side). > - when we detect an error, it's useful to consider all possible causes and > consequences before deciding to make things worse (e.g. killing a > session/transit node/prefix). In particular, there may not be a single error > but > many (SIDs, source routers (especially if the error is on the receiving > side)). So > it's useful to consider that the decision may be multiplied 10 or 100 times. > > Clearly there are difference between IGP & BGP: usually more redundancy in > BGP (more signaling path (redundant RR) and more AS exit points), more > prefixes hence the cost of dropping one prefix is relatively less important, > two-way point to point signaling channel, messages are flooded unchanged so > people are less likely to shoot the messenger and errors are less likely to be > multiplied during propagation.... > > __ > "An > alternative is to ensure at the nodes which originate these > advertisements that no such overlap is allowed to be configured. > Such overlaps can then be considered as a conflict if they are > received. This allows a simpler and more efficient implementation of > the database. This is the approach assumed in this document." > > I encourage implementation to check the configurations before accepting it. > And to check its routing advertisement before sending it. I would assume that > state of the art implementation will do it. Yet, I don't think it should be > considered as an excuse to avoid error handling at the protocol level. > BTW, I'm not sure how much you expect implementation checks to be done > before committing/sending. e.g. If an operator configure a range on the SRMS, > and this ranges conflict with existing SID advertised by other nodes, would > you > expect the implementation to detect such conflict and reject the > configuration? > More generally, if we assume some extensive checks by implementations > before committing/sending, and that given such assumption we define a light > error handling, I'd like such assumptions be documented in the document and > probably be made normative (since the receiving side, is expected a specific > behavior from the sending side, this is normative). > Also "implementation of the database" is implementation dependent and is > probably just one aspect of the implementation simplicity/efficiency. > And speaking for myself, simplicity/efficiency/availability of 100s networks > running segment routing significantly out weight the "simplicity and > efficiency" of one to ten implementations. > > __ > "The occurrence of conflicts is > easily diagnosed from the behavior of the network as the forwarding > of traffic which would, in the absence of conflicts, utilize > segments no longer does so." > > I don't think that we need to kill customer's traffic to raise awareness of > the > network operator. And I don't support the idea that the more traffic you kill, > the easier and faster the error is resolved. > If you need to raise an error, please do so! e.g. in logs, syslogs, SNMP > traps, > netconf event notification... Dropping the traffic is not providing more > information, it is increasing the pressure and hence the probability of quick > erroneous actions. Not to mention that as all services will run over packet > networks, and as there is a pressure to reduce costs we may have a single > converged network for all services. In this case, there is a chance that if > the > network is down, some people/tools/equipment may not be reached > anymore/easily. e.g. calling people on their cell phone does not work when > the packet network is down. > > __ > " The downside of ignoring conflicting entries is that forwarding of > all packets with destinations covered by the conflicting entries will > always be negatively impacted." > > Let's call a spade a spade. (btw, I prefer the French version :s/spade/cat > which nowadays should be more popular on the Internet ;-) ) The traffic is not > "negatively impacted", the traffic is "dropped". And for all > services/customers/BGP routes using theses SIDs. > > __ > 3.2.2. Preference Algorithm > [...] > "This approach requires that conflicting entries first be identified" > > All approach requires conflicting entries to be identified. This is not a > drawback of the "preference algorithm" > > "Based on which entry is preferred this in turn may impact what other entries > are considered in conflict" > > This is not additional rule/work. This is applying the same rule/algo to > subsequent entries. > Also, from the network perspective, in the end, this will not drop more > entries > than the "ignore rule", quite the contrary. > > "Based on > which entry is preferred this in turn may impact what other entries > are considered in conflict i.e. if A conflicts with B and B > conflicts with C - it is possible that A does NOT conflict with C. > Hence if as a result of the evaluation of the conflict between A and > B, entry B is not used the conflict between B and C will not be > considered." > > I'm not sure to get what is implied. As A and B conflicts and B and C > conflicts, > with "ignore conflicting entries", I would assume that all A, B, C be ignored, > no? Or do you plan to ignore conflicting entries until there is no conflict? > In > which case we would only remove one of the two conflicting entries and end > up with a "preference" resolution 'and never drop both conflicting entries > since once we drop the first, there is no more conflict) ___ > > > > ____________________________________________________________ > ____________________________________________________________ > _ > > 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. _________________________________________________________________________________________________________________________ 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
