Hi Pushpasis,
On 8/19/15 07:44 , Pushpasis Sarkar wrote:
Hi Peter,
On 8/18/15, 9:50 PM, "spring on behalf of Peter Psenak"
<[email protected] on behalf of [email protected]> wrote:
Hi Eric,
please see inline:
On 8/18/15 17:18 , Eric C Rosen wrote:
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
for the true multi-topology case with single IGP above is what both OSPF
and ISIS SR extensions have been assuming - there is no MTID advertised
with SRGB, but there is one advertised with prefix SID.
[Pushpasis] What if the same prefix is advertised by same IGP instance
under two different topology? I think the point Eric is trying to make is
valid. The SR architecture document does not really clarify this scenario.
SR protocol extensions clearly do - they advertise MTID with the prefix
SID, not with SRGB.
Again, following the same logic as given for per-protocol SRGB (actually
per-protocol per-instance) a separate SRGB should be provisioned
per-protocol per-instance and per-topology instead of assigning a separate
SID-Index for each topology.
For the multiple instances of one or the other IGP running in parallel
(assuming same topology), same SRGB and SID for prefix could be used by
all of them, although it should not be mandated.
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.
I would say optional SRGB per IGP instance - and that is what I believe
we have concluded so far throughout the discussion.
[Pushpasis] Yes. However if you really see the implication of that
consensus on a router with multiple routing-instances, it means one SRGB
per-protocol per-instance.
Did I say anything else?
thanks,
Peter
thanks,
Peter
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
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
