Hi All, Without trying to drag myself into any controversial discussion, just wanted to remind everyone, that we have already discussed on this list, that there are use cases (e.g. Data-centers) where we need non-overlapping per-protocol SRGBs to simplify SID-Index-Space management.
Considering a single DC-Gw router participating in the DCI-core as well as the DC, a non-overlapping per-protocol SRGB shall be needed on such a node if the same set of indexes can be assigned to two different routers one in DCI and another in DCN. On the DC-Gw router they should be forwarded using two different label. Thanks -Pushpasis On 1/7/16, 10:43 PM, "spring on behalf of Les Ginsberg (ginsberg)" <spring-boun...@ietf.org on behalf of ginsb...@cisco.com> wrote: >Stephane - > >I know that you are well versed in this issue from the discussion we had some >time back on the SR YANG model. :-) > >At that time we agreed that SRGB logically belongs at global scope - though >there are some use cases where we may want per protocol SRGBs. > >https://www.ietf.org/id/draft-ietf-spring-sr-yang-01.txt currently says >(Section 3): > >"SRGB (Segment Routing Global Block): Defines a list of label > blocks represented by a pair of lower-bound/upper-bound labels. > The SRGB is also agnostic to the control plane used. So all > routing-protocol instance will have to advertise the same SRGB." > >This covers the vast majority of use cases (and lets please not use this >thread to discuss the exception cases :-) ). > >However, because we know there are use cases where the above may not be true, >I would like not to prevent (or make more difficult) solutions to the cases >where we need per protocol SRGBs. I think we get a significant benefit from >doing per protocol validation - the implementation of that is much simpler >than doing cross protocol validation - and we do not prevent the exception >cases where we need per protocol SRGB from being supported in the future. > >Does this seem fair to you? > > Les > > >> -----Original Message----- >> From: stephane.litkow...@orange.com >> [mailto:stephane.litkow...@orange.com] >> Sent: Thursday, January 07, 2016 8:13 AM >> To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN >> Cc: spring@ietf.org >> Subject: RE: draft-ginsberg-spring-conflict-resolution >> >> 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 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
