Hi, So we agree that you can't write a draft to define SRGB errors as those are local design choices. Done with that :)
As far as "SID conflict" I am not sure I would agree too ... if I can tunnel to an anycast IP address why I can not tunnel to anycast SID - configured as same on N different nodes ? The only sort of error which I see so far to be detected is overlapping ranges being advertised by single node and current trend is to detect it during configuration. But is this really an error ? Why can't we just treat overlapping ranges as such and once received construct a SRGB for a given node out of those overlapping or not overlapping ranges ? Cheers, R. On Fri, Jan 8, 2016 at 10:23 AM, <stephane.litkow...@orange.com> wrote: > Hi Robert, > > > > Regarding SRGB management, it’s really a design choice. There was already > some discussion in the past. > > If people/implementations uses a global SRGB which is agnostic to > protocols, cross protocol validation does not really make sense. > > If people/implementations uses per protocol SRGB, cross protocol > validation makes sense. > > I do not see a real use case for the partial overlapping between protocols. > > > > I agree with you that using a common SRGB for all protocols works well and > only SID conflict management in necessary in this case. > > > > Brgds, > > > > Stephane > > > > > > *From:* rras...@gmail.com [mailto:rras...@gmail.com] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, January 07, 2016 17:19 > *To:* LITKOWSKI Stephane SCE/OINIS > *Cc:* Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; spring@ietf.org > *Subject:* Re: [spring] draft-ginsberg-spring-conflict-resolution > > > > Hi Stephane, > > > > > For example, if user tries to configure a BGP SRGB that > > > overlaps with ISIS SRGB > > > > Can you elaborate why that would be a bad thing to have two protocols > advertise even not partially overlapping but identical SRGB from a given > node ? > > > > Also while we are at the node doing the check during configuration let's > do not forget that not all configurations these days are real time and > inline. To add concepts of forward referencing are also used which may > allow on purpose to configure overlapping blocks before even given IGP (or > protocol in general) is activated on any interface. > > > > Best, > > r. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jan 7, 2016 at 5:12 PM, <stephane.litkow...@orange.com> wrote: > > Hi, > > [Les:] I am not proposing that we do cross-protocol validation of SRGBs. > This would indeed increase the complexity and I am not convinced we would > gain much. > SID conflict detection is a different matter - there we do indeed want to > include all protocols. > > [SLI] IMO, complexity of SRGB cross protocol validation depends on how > the implementation is done. The SRGB may or may not really be owned by the > protocol directly. Protocol just do the advertisement, but SRGB may be > owned by SR that may do suballocation for a particular protocol. That > really depends on how it has been coded. I'm not sure that in Cisco > implementation that ISIS requests label range directly from the label > manager ? If "SR process" owns all the labels and just receive requests > from protocols to reserve a particular SRGB, it has the global view and can > manage overlap easily. For example, if user tries to configure a BGP SRGB > that overlaps with ISIS SRGB, it can be easily refused by the SR process. > > So we go back to the question of the requirements ... I think it would be > really helpful that the WG agree on the requirement before talking about > solutions. > > > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] > Sent: Thursday, January 07, 2016 00:03 > To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS > Cc: spring@ietf.org > > Subject: RE: draft-ginsberg-spring-conflict-resolution > > Bruno - > > I think there are two questions for me below - look for my answers inline. > Let me know if I missed anything. > > > -----Original Message----- > > From: bruno.decra...@orange.com [mailto:bruno.decra...@orange.com] > > Sent: Wednesday, January 06, 2016 10:04 AM > > To: LITKOWSKI Stephane SCE/OINIS > > Cc: spring@ietf.org; Les Ginsberg (ginsberg) > > Subject: RE: draft-ginsberg-spring-conflict-resolution > > > > 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; spring@ietf.org; 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. > > > > [Les:] I am not proposing that we do cross-protocol validation of SRGBs. > This would indeed increase the complexity and I am not convinced we would > gain much. > SID conflict detection is a different matter - there we do indeed want to > include all protocols. > > > > > > > > - §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? > > > [Les:] I "think" you are referring to this text from the IS-IS draft > (Section 2.4.5): > > " 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." > > This text should be removed - the protocol drafts should simply reference > the spring-conflict-resolution draft. Indeed one of the motivations for > spring-conflict-resolution draft is to unblock the protocol drafts and > isolate the conflict resolution to a single common draft. This means the > protocol drafts MUST be agnostic and if they say anything at all it would > be to reference spring-conflict-resolution draft. > > Les > > > > > > > - 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:spring-boun...@ietf.org] On Behalf Of > > > bruno.decra...@orange.com > > > Sent: Thursday, December 17, 2015 18:27 > > > To: spring@ietf.org; 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-h > > > an > > > dling-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. > > > _________________________________________________________________________________________________________________________ > > > 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 > spring@ietf.org > 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring