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]]
Sent: Friday, July 01, 2016 3:36 AM
To: DECRAENE Bruno IMT/OLN
Cc: [email protected]<mailto:[email protected]>
Subject: RE: draft-ietf-spring-conflict-resolution
Bruno -
Inline.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Thursday, June 30, 2016 5:10 AM
To: Les Ginsberg (ginsberg)
Cc: [email protected]<mailto:[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]]
Sent: Wednesday, June 29, 2016 6:19 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email protected]<mailto:[email protected]>
Subject: RE: draft-ietf-spring-conflict-resolution
Bruno -
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Wednesday, June 29, 2016 7:22 AM
To: Les Ginsberg (ginsberg)
Cc: [email protected]<mailto:[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 :)
[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]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Wednesday, May 18, 2016 1:57 PM
To: Les Ginsberg (ginsberg); [email protected]<mailto:[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]]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; [email protected]<mailto:[email protected]>
Subject: RE: draft-ietf-spring-conflict-resolution
Bruno -
Inline.
From: spring [mailto:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Thursday, May 12, 2016 8:23 AM
To: [email protected]<mailto:[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. :)
[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]] > 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
