Subject: Re: [spring] draft-ietf-spring-conflict-resolution

From: <[email-masked]>
Date: Wed, 29 Jun 2016 14:22:26 +0000

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.

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).

I'm also not sure to see why is the problem different compared to Multi-Topology. Could you please elaborate?

Thanks,
Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

Les,

Thanks for your reply.
Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-spring-conflict-resolution

Bruno -

Inline.

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, May 12, 2016 8:23 AM
To: [email-masked]<mailto:[email-masked]>
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. :)
[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-masked]] > 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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 Jun 2016 16:18:36 +0000

Bruno -

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
Subject: RE: draft-ietf-spring-conflict-resolution

Hi Les,

[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 :)

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.

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. 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.

[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.

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.

    Les

Thanks,
Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

Les,

Thanks for your reply.

Bruno -

Inline.

Hi,

   selection algorithm. »

§3.1

"a" requires this draft

   Les

Thanks,
Regards,
Bruno

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 30 Jun 2016 07:56:50 +0000

Hi Les,

Administrative distance (protocol preference) has always been used in router implementation for a while. Yes inconsistent configuration of admin distance can cause routing issues (loops or whatever ...). I'm not sure we can really bypass it ...
Regarding the preference algorithm, the SRMS weight must also need to be taken into account (as stated by Stefano, the conflict draft will need to be updated accordingly). We may be able to put it just after PFX > SRMS.

One other point regarding the draft is that it must be stated clearly that the different approach presented cannot be mixed in a network deployment, otherwise inconsistent behavior may occur.

The last point, as Bruno, from an operational network perspective, I'm more in favor to push the ignore overlap only rather than the quarantine which could break forwarding to a lot of destinations.

Best Regards,

Stephane

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, June 29, 2016 18:19
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: Re: [spring] draft-ietf-spring-conflict-resolution

Bruno -

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-spring-conflict-resolution

Hi Les,

    Les

Thanks,
Bruno

Les,

Thanks for your reply.

Bruno -

Inline.

Hi,

   selection algorithm. »

§3.1

"a" requires this draft

   Les

Thanks,
Regards,
Bruno

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 30 Jun 2016 12:09:43 +0000

Hi Les,

Thanks for the discussion. Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Wednesday, June 29, 2016 6:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: RE: draft-ietf-spring-conflict-resolution

Bruno -

Hi Les,

[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.

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)

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.

[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

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

    Les

Thanks,
Bruno

Les,

Thanks for your reply.

Bruno -

Inline.

Hi,

   selection algorithm. »

§3.1

"a" requires this draft

   Les

Thanks,
Regards,
Bruno

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 1 Jul 2016 00:14:13 +0000

Stephane -

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 30, 2016 12:57 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN
Cc: [email-masked]
Subject: RE: draft-ietf-spring-conflict-resolution

Hi Les,

Administrative distance (protocol preference) has always been used in router implementation for a while. Yes inconsistent configuration of admin distance can cause routing issues (loops or whatever ...). I'm not sure we can really bypass it ...
[Les:] First, you do not address the lack of admin distance for SRMS entries - which for me is sufficient to make the use of this attribute inappropriate in this context.
Second, inconsistency in admin distance config is always potentially dangerous, but when applied to local route preference it simply means that the local router chooses to follow the path provided by Protocol A rather than Protocol B. So long as it sends this to a node which is running Protocol A presumably the packet still has a chance to be forwarded to its destination. In the case of SIDs however, using a different SID means that the label used to forward the packet is likely to  be interpreted differently by nodes along the path - so the risk of misforwarding is significant.
Finally, we have deliberately made the conflict resolution protocol independent so as to allow consistent resolution when multiple protocols are in use. Using admin distance runs counter to that model.

[Les:] Yes, we started to incorporate that, but we discovered that OSPF currently has no equivalent to the "weight" field in IS-IS Binding TLV entries. This is because SRMS advertisements in OSPF use the Extended Prefix Range TLV and the Prefix SID sub-TLV  (see https://www.ietf.org/id/draft-ietf-ospf-segment-routing-extensions-08.txt - Sections 4 and 5). The only reason IS-IS has "weight" is because it was put into the Binding TLV in support of other use cases (various ERO objects) - not for SRMS advertisements. This also got us thinking that the granularity of preference between mapping servers is more logically associated with the server - not with an individual advertisement from that server. Which in turn suggests a new extensions to per node SR Capabilities advertisements would be more appropriate.

None of this has yet been discussed publicly - so we do not know what direction the WG may want to go as regards SRMS and "weight". We therefore left it out of this revision of conflict resolution.

[Les:] The point of the draft is to (based on consensus) define one - and only one - conflict resolution policy which all nodes MUST support. The fact that alternatives are currently discussed in the draft is a reflection of the current draft state (still evolving) - not an indication that we are going to allow multiple algorithms to be deployed.

[Les:] Thanx for the input.

   Les

Best Regards,

Stephane

Bruno -

Hi Les,

    Les

Thanks,
Bruno

Les,

Thanks for your reply.

Bruno -

Inline.

Hi,

   selection algorithm. »

§3.1

"a" requires this draft

   Les

Thanks,
Regards,
Bruno

Thank you.

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 1 Jul 2016 01:35:34 +0000

Bruno -

Inline.

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]
Subject: RE: draft-ietf-spring-conflict-resolution

Hi Les,

Bruno -

Hi Les,

[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.

[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. 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. 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.

[Les2:] Please see my response to Stephane on the same point.

[Les2:] Please reread Section 3.1.2. While there are no "Prefix-conflicts" across topologies, there are "SID Conflicts". This is important to understand.
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

Les,

Thanks for your reply.

Bruno -

Inline.

Hi,

   selection algorithm. »

§3.1

"a" requires this draft

   Les

Thanks,
Regards,
Bruno

Thank you.

Thank you.

Thank you.

Thank you.