Hi Les, > However, this is not existing MPLS forwarding behavior and since SR > explicitly utilizes the existing MPLS forwarding behavior we not propose > any extensions.
I am afraid the above assertion is not correct. Existing MPLS forwarding already for a long time uses context-labels to set required topology for forwarding. https://tools.ietf.org/html/rfc5331 Thx, R. On Tue, Jul 5, 2016 at 9:19 AM, Les Ginsberg (ginsberg) <[email protected]> wrote: > Bruno – > > > > SR-MPLS utilizes existing MPLS forwarding behavior without change. In this > model, the received label serves as the forwarding instruction for the > packet. This means that if two packets are received for the same > destination but we want the packet to follow two different forwarding > “topologies”, then we need to have two different labels. > > > > One can imagine a different model, where the forwarding instruction is > derived from the label AND some other attribute of the packet – and the > latter could be used to select a forwarding topology. However, this is not > existing MPLS forwarding behavior and since SR explicitly utilizes the > existing MPLS forwarding behavior we not propose any extensions. > > > > This is why different SIDs are required for the same destination in > different topologies. > > > > Les > > > > > > *From:* [email protected] [mailto:[email protected]] > *Sent:* Monday, July 04, 2016 5:07 AM > > *To:* Les Ginsberg (ginsberg) > *Cc:* [email protected] > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Les, > > > > Please see inline [Bruno3] > > > > *From:* Les Ginsberg (ginsberg) [mailto:[email protected] > <[email protected]>] > *Sent:* Friday, July 01, 2016 3:36 AM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* [email protected] > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Bruno – > > > > Inline. > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] > *Sent:* Thursday, June 30, 2016 5:10 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* [email protected] > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Hi Les, > > > > Thanks for the discussion. Please see inline [Bruno] > > > > *From:* Les Ginsberg (ginsberg) [mailto:[email protected] > <[email protected]>] > *Sent:* Wednesday, June 29, 2016 6:19 PM > *To:* DECRAENE Bruno IMT/OLN > *Cc:* [email protected] > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Bruno – > > > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] > *Sent:* Wednesday, June 29, 2016 7:22 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* [email protected] > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Hi Les, > > > > IINM, I’ve not seen the follow up on one of my below questions. > > So let me restate a comment: > > > > The SR-MPLS SID conflicts algo requires that all nodes consider the same > mapping advertisements. > > How is this ensured, if it indifferently considers advertisements from all > protocols, while some nodes could participate only in a subset of the > protocols? e.g. OSPF only routers would consider a different set of > information compared to OSPF+IS-IS routers. > > > > *[Les:] If you run multiple protocol instances (whether multiple instances > of the same protocol or instances of different protocols) then you need to > insure that at least one of the two conditions below is true:* > > · All routers receive the equivalent set of advertisements > > · There are no conflicts J > > > > [Bruno] IOW, the draft does not resolve SID conflict if all routers do not > receive exactly the same set of advertisement from all routing protocols. > > That’s indeed can be a valid simplification if the WG choose to, but this > should clearly be indicated in the document, in a section targeting network > operator since this point will need to be read and enforced by network > operator rather than protocol implementors. §3.2.8 already partly address > this, but IMO a text clearly expressing the requirements on network > operator would be useful. > > > > *[Les2:] No policy can guarantee consistent results network wide if the > databases on different nodes are inconsistent. This isn’t a > “simplification” – it is a fact. As you point out, Section 3.2.8 already > states:* > > > > *“In order to obtain consistent active entries all nodes in a network* > > * MUST have the same mapping entry database.”* > > > > *If you believe this is not explicit enough please suggest some text.* > > [Bruno3] > > Section 4 Manageability Considerations > > Detecting and resolving conflicts in a consistent way requires that all > nodes consider the same set of SIDs advertisements. Network operations > should be aware that the conflict resolution algorithm defined in this > document will not succeed in selecting a consistent resolution across all > nodes, if all nodes do not receive the exact same set of SIDs > advertisements. This may be in particular the case when multiple IGP > instances are used and all routers do not participate in the same set of > IGP instances. This may occurs for example if one network transition from > one IGP protocol to another IGP (e.g. from OSPFv2 to IS-IS). This may also > happen if IGP areas/level are used and SIDs are not flooded in all > areas/levels. > > > > > > *One way of insuring the first point is to exclusively use a mapping > server to advertise SIDs, configure your SRMS entries in a protocol > independent manner, and insure that the SRMS advertisements are sent in all > of the protocol instance specific sub-domains.* > > [Bruno] IOW, don’t make configuration errors ;-) > > Are you implying that the SRMS configuration (hence yang model) should be > per node rather than per protocol? or at least should be configurable by > node (and possibly also by protocols) > > > > *[Les2:] My point is (humorous ideas aside…) that if a deployment uses > multiple protocols, the easiest way to guarantee that the SID mapping > database on all nodes in the network is consistent is to restrict SID > advertisements to SRMS advertisements.* > > [Bruno3] Clearly, the fewer the number of advertisements for a given > prefix, the less change of conflict. > > But I fail to see why only using SRMS guarantee anything. e.g. if > different nodes use a different set of routing protocols, you have > conflicts. Idem if the misconfiguration consist in adding a SID to a IGP > prefix (PFX advertisement) > > > > > > *A small number of nodes (as few as 1 – more if redundancy is desired) are > setup as mapping servers and all SIDs which are required network-wide are > configured on these nodes and advertised by the protocol instance(s) on > that node. In this way it is not necessary to guarantee that all prefix > reachability from all of the protocol instances running in the network are > present in all the protocol instance sub-domains which exist – it is only > necessary to insure that all protocol instances advertise the same set of > SRMS entries.* > > [Bruno3] In the end, this gets back to requiring no configuration mistakes. > > *It isn’t the only way to support this – but it is likely to be the > simplest and least error prone. In any case this isn’t a requirement – it > was a response to your question as to how it might be possible to get > consistent SID mapping databases on all nodes in such a case. This is no > way changes how the YANG model is defined. SRMS config is always node > specific.* > > > > > > *If the intent is to deliberately use different labels in the forwarding > plane for the same destination depending upon which protocol advertised the > prefix, this introduces a number of new requirements – not the least of > which is duplicate entries for the same prefix in the forwarding plane. As > has been discussed publicly in a different thread, there are cases (e.g. > merging two networks) were such a requirement may exist – but it is the > exception rather than the rule and as it consumes more resources in the > forwarding plane and introduces implementation complexity independent of > conflict resolution it is not the primary case the draft focuses on. > Nevertheless, this is a case which the draft will address in the next > revision.* > > [Bruno]There is also the point of configuring different SRGB space in > different IGP protocols. In which case, SIDs may conflict but this is not > an issue as label will not conflict. > > *We stopped short of that in this revision because we felt there were > enough substantive changes and points on which consensus is still a work in > progress that it would not be the optimal way forward.* > > [Bruno] +1 and thanks. Releasing an updated version has been useful to > re-initiate the discussion. > > > > Thinking more about this, I guess that this is only important for the > entries which are inserted in the forwarding plane. Hence, in case of > conflict between protocols, I think that the preference algorithm should > take into account the protocol preference (aka administrative distance). > > > > *[Les:] As admin distance is neither an attribute of SRMS entries nor > guaranteed to be consistent on all routers for all prefixes this is not a > desirable approach. * > > [Bruno] Well, the some prefix/routing consistency is also required for IP > prefixes. When then same IP prefix is advertised in different IGPs, admin > distance is a common existing way to define which routing protocol takes > precedence. I’m not sure why it should not also be taken into consideration > for SR Prefix conflits > > > > *[Les2:] Please see my response to Stephane on the same point.* > > > > I’m also not sure to see why is the problem different compared to > Multi-Topology. Could you please elaborate? > > *[Les:] I am unclear what your question is. Are you asking why we need > different SIDs in different topologies? Please clarify.* > > [Bruno] Question was that, at a very/too high level, the issue of conflict > across topology seems close to the issue of conflict across routing > protocols: we have different topologies. Hence a naïve question: how > exactly is this different. > > One part of the answer, is the simplification proposed when multiple > protocols is used (i.e. your first answer above). > > Another part is that for multi-topology, compared to multi-protocols, all > information from all topologies are flooded to all nodes. > > Another part is the forwarding model used for Multi-Topology. In general, > https://tools.ietf.org/html/rfc5120#section-8 seems to assume that each > topology has one dedicated RIB/FIB. In such condition, there is no conflict > (prefix or SID) so no need to detect and resolve conflict. So here there > may be different models and eventually, we don’t ‘have the same one in mind. > > In a lesser extend, even for multi-protocols, we may have those multiple > forwarding models. To some extent, this seems related to the definition of > “SR domain”. e.g. if we have 2 IGPs, do we have 1 or 2 SR domains? May be > this is something that needs to be configurable > > > > > > *[Les2:] Please reread Section 3.1.2. While there are no > “Prefix-conflicts” across topologies, there are “SID Conflicts”. This is > important to understand.* > > [Bruno3] Conflicts are related to a forwarding context i.e. FIB. This is > equally important to understand. Please read > https://tools.ietf.org/html/rfc5120#section-8.2.2 and 8.2.1 to see that > topologies may not share the same forwarding context hence do not conflict > in term of prefix & SID. > > --Bruno > > > > *As regards multiple protocols operating in the same topology, from a > forwarding perspective we do not care what protocol is the winning route. > What we care about is that our nexthop has chosen the same SID for a given > prefix. This is why “source” is deliberately excluded from consideration by > the conflict resolution algorithm.* > > > > * Les* > > > > * Les* > > > > > > Thanks, > > Bruno > > > > *From:* spring [mailto:[email protected] <[email protected]>] *On > Behalf Of *[email protected] > *Sent:* Wednesday, May 18, 2016 1:57 PM > *To:* Les Ginsberg (ginsberg); [email protected] > *Subject:* Re: [spring] draft-ietf-spring-conflict-resolution > > > > Les, > > > > Thanks for your reply. > > Please see inline [Bruno] > > > > *From:* Les Ginsberg (ginsberg) [mailto:[email protected] > <[email protected]>] > *Sent:* Saturday, May 14, 2016 8:30 PM > *To:* DECRAENE Bruno IMT/OLN; [email protected] > *Subject:* RE: draft-ietf-spring-conflict-resolution > > > > Bruno – > > > > Inline. > > > > *From:* spring [mailto:[email protected] <[email protected]>] *On > Behalf Of *[email protected] > *Sent:* Thursday, May 12, 2016 8:23 AM > *To:* [email protected] > *Subject:* [spring] draft-ietf-spring-conflict-resolution > > > > Hi, > > > > As an individual contributor, please find below some comments: > > > > -- > > Isn’t this document specific to the MPLS dataplane? > > If so, it could be indicated in the introduction, and possibly in the > abstract. Then this indication could be removed from the 1rst sentence of > sections 2 & 3. > > > > *[Les:] Currently all discussion is regarding SR-MPLS. The draft leaves > open the possibility that if there is some SRv6 conflict resolution that > needs to be specified it could be added into this document – which is why > the Introduction is dataplane agnostic, but each section states > specifically that it is relevant to SR-MPLS.* > > > > *I am not aware of any SRv6 conflict resolution that is required at this > point, but I prefer to leave the possibility open if that is OK with you.* > > [Bruno] ok, great. > > -- > > §3 > > “Mapping entries have an explicit context which includes the topology and > the SR algorithm.“ > > A priori you could add “the routing protocol”. > > > > *[Les:] No – the source of advertisements is deliberately left out. It > matters not whether the source of the advertisement is a protocol or an > SRMS – nor does it matter which protocol provides the advertisement. You > see that “admin distance” is not mentioned at all and that is quite > deliberate. This insures that consistent choices are made on nodes > regardless of which protocol might have the best route on a given node.* > > [Bruno] Well, the fact is that mapping entries do have, as explicit > context, the routing protocol used to advertise them. After, you can should > to use that information, or not. > > -- > > §3 > > “When conflicts occur, it is not > > possible for routers to know which of the conflicting advertisements > > is "correct". If a router chooses to use one of the conflicting > > entries forwarding loops and/or blackholes may result unless it can > > be guaranteed that all other routers in the network make the same > > choice. Making the same choice requires that all routers have > > identical sets of advertisements and that they all use the same > > selection algorithm. » > > > > I think we agree on the technical part, but I found the formulation slightly > biased. I would propose > > “When conflicts occur, it is not > > possible for routers to know which of the conflicting advertisements > > is "correct". In order to avoid forwarding loops and/or blackholes, there > is a need for all nodes to make the same choice. > > Making the same choice requires that all routers have > > identical sets of advertisements and that they all use the same > > selection algorithm. This is the purpose of this document. » > > -- > > *[Les:] I am fine with this change.* > > [Bruno] Thanks > > > > §3.1 > > “Various types of conflicts may occur” > > What about :s/Various/Two > > > > *[Les:] “Two” is fine. Just means we will have to change it if we come up > with a third type of conflict. **J* > > [Bruno] Indeed, but in this case the change may be much larger (e.g. the > whole algo) > > -- > > I agree with Robert’s and Uma’s comment with regards to making this > conflict resolution an inter- protocol/routing_table issue. In particular, > between SR domains, there is not requirement to have unique SIDs. Hence > between PE and CE, between ASes (both within and across organization), the > same SID could be reused independently). > > > > *[Les:] There is more to be said on this topic – co-authors are actively > discussing this point and we’ll respond more fully to Robert’s post in > time. But, the draft is NOT trying to define conflict resolution across “SR > domains”. Perhaps we need language to make that more explicit.* > > [Bruno] ok. Regarding inter-protocol, in order to have consistency of the > prefix-SID mapping across the domain we need: > > a) all nodes use the same algo > > b) all nodes using this algo have the same data > > > > “a” requires this draft > > “b” requires that all nodes have the same set of SR info. This forbid > that some node are considering IS-IS + OSPF SR data, while some node are > only considering IS-IS data. Otherwise, all IS-IS routers would not take > the same decision. So, unless we can guarantee that the flooding area is > the same for IS-IS and OSPF, we can't have the algo using the SR data from > multiple routing protocols. I don't think that we can guarantee this (nor > that implementation will check this) e.g. when some nodes are part of > multiple routing domain or when gradually transitioning from one IGP to > another. > > > > So in short, this SR-conflict algo should probably be restricted to SR > information from a single protocol > > > > > From: Les Ginsberg (ginsberg) [mailto:[email protected] > <[email protected]>] > Sent: Sunday, May 01, 2016 7:11 AM > > > > > > We are indeed defining conflict resolution across all the SID > advertisements regardless of source (protocol or SRMS) > > > Why? Because we need consistent use of SIDs in the forwarding plane > > > > No: in the forwarding plane, we need a consistent use of MPLS label. > > *[Les:] As you know, SRGB range can be different for different nodes, so > the actual label that is used to send a packet for a given destination via > Node A may be different than the label used to send the same packet via > Node B. It is the SID that needs to be the same – not the label. * > > *It is true that SIDs are not installed in the forwarding plane – the > labels derived from the SID/SRGB are what is actually installed in the > forwarding plane – but I think my use of the word SID in this context is > correct.* > > [Bruno] My point was that the formulation assumes that a single SRGB is > used per nodes. In which case, we have a bijection between SID and labels. > But if we have a SRGB per protocol, we don’t have a bijection any more and > we can have the same SID in IS-IS and OSPF (including for different > prefix), which will be mapped to different labels in the forwarding plane. > > > > Plus only within an SR domain. Actually, even within a domain, this is > dependent on whether SRGB is configured on a per node or a per protocol > basis. I’m not sure how much the agreement has been reached on that one. > > > > *[Les:] The draft currently addresses deployments where a single (set of) > SRGB ranges applies to the box. This is by far the most common use case. > There is a much more limited use case where protocol specific SRGBs and > protocol specific SIDs may be required. The draft will address that in a > future revision* > > [Bruno] ok, may be this should be stated in the draft, as otherwise you’ll > keep getting comments, or we may forget this point. > > Thanks > > --Bruno > > *– but in spirit the same rules will apply – they will just have to take > into account “duplicate forwarding domains”. Note that this will also > require multiple incoming label entries/prefix be supported by the routers > in such a network.* > > > > -- > > Typo: > > §2 > > OLD : Range 3: (500, 5990 > > NEW : Range 3: (500, 599) > > > > (somewhat significant as otherwise range 3 conflict with range 2) > > > > *[Les:] Agreed – thanx for spotting this.* > > > > *Les* > > > > Thanks, > > Regards, > > Bruno > > _________________________________________________________________________________________________________________________ > > > > 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. > > _________________________________________________________________________________________________________________________ > > > > 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 > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
