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