Hi Eric,
Regarding MT case, ยง3.2 states :
" A single Prefix-SID is allocated to an IGP Prefix in a topology.
In the context of multiple topologies, multiple Prefix-SID's MAY be
allocated to the same IGP Prefix (e.g.: using the "algorithm" field
in the IGP advertisement as described in IGP SR extensions
documents). However, each prefix-SID MUST be associated with only
one topology. In other words: a prefix, within a topology, MUST have
only a single Prefix-SID.
"
So it favors Alternative #1.
But the text is not really clear because :
- it does not talk about the "per-algorithm" case, just topology case
- it mixes algorithm and topology by saying " e.g.: using the "algorithm" field
in the IGP advertisement as described in IGP SR extensions
documents", which is bad as for true MT and even for multiple IGP instances,
the MT-ID should be used as discriminator and not the algorithm field.
Algorithm is something else. What if I want to do and IPv6 topology with SPT ?
Normally I still use algo 0 but with MT-ID corresponding to IPv6 topology ...
so algorithm and MT should not be mixed. For the multiple parallel IGP
instances case, all of them will also use algo #0 as we want SPT.
I agree that there s a need of consensus on the target solution as you propose
alternative #1 or #2 for algorithm, MT and protocol.
Allocating Prefix-SIDs is like allocating IP prefixes, there s should be a
registry at SP side to manage that.
In term of allocation method, alternative #1 is like a flat addressing plan, so
whatever the target element the IP address will be associated with, I just pick
up the next available one (or something like that). Alternative #2 is something
like prefix per function (that we usually do), so for a specific function (ex :
LNS Loopback or BGP peering loopback ...), I use a particular prefix, but the
suffix is the same, we can consider the SID value as the suffix and the SRGB as
the prefix and combination of both gives the label. I would agree that here in
reality when we see the label we do not see anymore this prefix+suffix. In both
cases, the label value would be different.
As I already pointed, from a deployment perspective, it's more painful to
reallocate a new SID each time we want to add a topology or algorithm. For sure
it will not be a day to day operation, but even if we do this once per 5 years,
this has a cost of many man months on a large network because it cannot be
fully automated (when OSS does not have API) while deploying a new SRGB can be
fully automated as there is no link with OSS at all.
Now another important point is the SRGB management in alternative #1 and #2.
Let's start with alternative #2, if I want to implement a new algorithm or
topology or protocol, I need to allocate a new SRGB. So there is a need to
configure a new label block.
As the node is maybe running for a while, label space may be fragmented and it
may be hard :
- for sure , to allocate the label block the user wants
- in some rare case, to allocate a single block with the requested size (due
to fragmentation of label space)
So the requested label block will be configured but not allocated, requiring a
reboot to allow the allocation. This reboot has also an operational cost
expressed in man months. If the user wants to prevent the reboot, it should let
the box allocate any SRGB range taking into account the state of the label
space available.
Now alternative #1, there is a chance with alternative#1 that the SRGB that has
been configured is too small because I will need to twice more indexes. If I
already allocated 2000 indexes, I will need 2000 indexes more.
SRGB extension has the same issue as allocating a new SRGB.
In conclusion, why not letting the choice to the user ? so creating an
alternative #3, where the encoding allows to have a different SRGB per
protocol, per topology, per algorithm but then the user can decide to use the
same in configuration. So from encoding perspective it's alternate#2, but from
a config perspective it allows for both.
Example : common SRGB for everything
segment-routing
srgb 100 1000
!
Router isis
Topology #1
Interface eth1
Index 10 algorithm 0
Index 20 algorithm 1
Topology #2
Interface eth1
Index 30 algorithm 0
!
Router ospf
Interface eth1
Index 40 algorithm 0
!
Result encoding would be that the same SRGB will be advertised multiple times
for each activated protocol/algorithm/topology, in this case the SRGB will be
advertised 4 times :
SRGB 100 1000, algo 0, topo 1 in ISIS protocol
SRGB 100 1000, algo 1, topo 1 in ISIS protocol
SRGB 100 1000, algo 0, topo 2 in ISIS protocol
SRGB 100 1000, algo 0, base topo in OSPF protocol
Example : different SRGB
segment-routing
srgb 100 1000
!
Router isis
Topology #1
Srgb 2000 3000 algo 0
Srgb 3000 4000 algo 1
Interface eth1
Index 1 algorithm 0
Index 1 algorithm 1
Topology #2
Srgb 4000 5000 algo 0
Interface eth1
Index 1 algorithm 0
!
Router ospf
Srgb 5000 6000 algo 0
Interface eth1
Index 1 algorithm 0
!
Result encoding would be :
SRGB 2000 3000, algo 0, topo 1 in ISIS protocol
SRGB 3000 4000, algo 1, topo 1 in ISIS protocol
SRGB 4000 5000, algo 0, topo 2 in ISIS protocol
SRGB 5000 6000, algo 0, base topo in OSPF protocol
Best Regards,
Stephane
-----Original Message-----
From: spring [mailto:[email protected]] On Behalf Of Eric C Rosen
Sent: Tuesday, August 18, 2015 17:18
To: SPRING WG
Subject: [spring] SRGBs, indexes, and topologies within a domain
I've been following the "Modeling SRGB Configuration for
draft-ietf-spring-sr-yang" thread on this mailing list. I think this
discussion reveals an inconsistency in the architecture (as described in
draft-ietf-spring-segment-routing-04), and this inconsistency needs to be
resolved.
From the spring architecture:
Global Segment: the related instruction is supported by all the SR- capable
nodes in the domain. In the MPLS architecture, a Global Segment has a
globally-unique index. The related local label at a given node N is found by
adding the globally-unique index to the SRGB of node N. In the IPv6
architecture, a global segment is a globally- unique IPv6 address.
and
IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP
segment attached to an IGP prefix. An IGP-Prefix Segment is always
global within the SR/IGP domain and identifies an instruction to forward
the packet over the ECMP-aware shortest-path computed by the IGP to the
related prefix. The Prefix-SID is the SID of the IGP- Prefix Segment.
The first paragraph above makes it pretty clear that a node is supposed
to have only one SRGB. So even though there seems to be consensus for
allowing an SRGB per protocol in the Yang model, that seems to be at
odds with the architecture.
However, I think the second paragraph quoted above contradicts the first
paragraph. A given network may have multiple topologies, and the paths
for a given prefix may be different in each topology. There are
numerous ways to set a network up with multiple topologies. One can
have OSPF and ISIS running in parallel, or one can have multiple
instances of one or the other IGP running in parallel, or one can use
the explicit multi-topology feature that each IGP has. An IGP-Prefix
Segment would then have to be understood as an instruction to forward a
packet over the ECMP-aware shortest-path computed by a particular IGP
instance over a particular topology.
I think it is clear that in such a scenario, one cannot use the same
MPLS label for a given prefix in all the topologies -- the label must be
per-prefix/per-topology. Since the label is computed from the
combination of the prefix-SID and the SRGB, this forces us to make a
choice between the following two alternatives:
1. Assign multiple SIDs to a given prefix, one per topology (i.e., the
prefix-SID is not domain-wide unique, but only topology-wide unique), or
2. Assign a different SRGB to each topology (not merely a different one
to each IGP).
The paragraphs I quoted from the architecture seem to prohibit both
these alternatives, effectively prohibiting the use of multi-topology
techniques in a spring domain. I'm assuming that that was not the
intention.
Reading the thread on representing the SRGB in the yang model, I'd
conclude that most folks seem to want to be able to assign a domain-wide
unique index to the prefixes, which requires alternative 2. But in this
case, the index is not "an instruction to forward the packet" over a
particular path, it's just an abbreviation for the prefix.
My conclusion is that unless we really want to prohibit the use of
multiple topologies in a spring domain, we need to choose between
alternatives 1 and 2 above, and the architecture needs to be adjusted
accordingly.
BTW, I don't think this issue is just a rehash of the old "should we
have global labels?" argument, and we shouldn't approach it that way.
In a multi-topology scenario, alternative 2 does seem to have some
operational advantages. In a scenario where there is a single topology,
but multiple routing algorithms are combined to create it, one could
always assign the same SRGB to each algorithm. Perhaps each node should
be configurable with a default SRGB and an optional SRGB per topology.
That would give operators the maximum freedom to support both
single-topology and multi-topology scenarios as they see fit.
Comments?
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
