Robert,
On 8/25/15 11:05 , Robert Raszuk wrote:
Peter,
"You can partition it in many ways, but the block is just one."
As you recall mpls architecture does not have such limitation. You can
have per interface overlapping label space.
Likewise to me SRGB blocks for MT or MI do not need to be continuos what
your earlier suggestion regarding offset would result with.
So I think the crux of this entire debate is this: are we allowing non
continous SRGB pools per node or not (say one per topology).
No matter how many partitions you have, still it's a single block
consisting of multiple partitions.
Yes, we are allowing non continuous SRGB per node - you can advertise
multiple SRGB blocks per node - please see the OSPF/ISIS SR extensions.
thanks,
Peter
If not what you and Les are saying may indeed be ok, however for
deployment flexibility I would rather tend to opt for it.
Best,
R.
On Aug 25, 2015 9:48 AM, "Peter Psenak" <[email protected]
<mailto:[email protected]>> wrote:
Hi Eric,
please see inline:
On 8/24/15 17:08 , Eric C Rosen wrote:
> [Peter] What you need is a different label for same prefix per
> MTID/algorithm - that we agree on. To achieve that you either need
> single SID and per MTID/algorithm SRGB or single SRGB with per
> MTID/algorithm SIDs.
>
> Peter, my reading of the architecture is that a prefix-SID is
"global"
> and that an SRGB is per-node.
Prefix SID has a prefix scope, SRGB has a node scope.
>
> This seems to be at odds with the way the control plane encodings
have
> been defined, which suggests that either the architecture or the
> encodings needs adjustment.
I do not see any odds with the encodings. Current IGP encoding supports
SRGB per each instance of the IGP.
>
> Recall that this discussion started with a claim that even one
SRGB per
> algorithm was in violation of the architecture.
SR architecture never claimed per algorithm SRGB.
>
> If we assume that the signaling drafts capture what the
architecture is
> supposed to have said, then I see the following issues.
>
> 1. If a new topology is added by use of the MT features of an
IGP, then
> a new set of prefix-SIDs must be provisioned. This seems like a
major
> provisioning task. The alternative would be to have an SRGB per
> topology; then when you add a new topology, you only have one
quantity
> to provision (or one per platform perhaps). I hear some hand-waving
> about how easy it is to provision new prefix-SIDs for every new
> topology, but ...
I will keep repeating myself that such provisioning can be made
automatic, so the above point is not really convincing to me.
>
> 2. The multi-topology feature of an IGP is just one way of setting up
> multiple "underlays". If you set up two underlays by using two
> instances of OSPF, you can assign a SRGB to each underlay. If
you set
> up two underlays by using two topologies in one instance of OSPF, you
> can't. Why the difference? I find this really confusing -- exactly
> what is the scope of uniqueness of a prefix-SID supposed to be?
the difference is because SRGB is a node property and SID is a prefix
property. Each prefix can have many attributes and SID is just another
prefix attribute. It's similar to prefix metric, which has a per
topology scope. SRGB is like any other node capability. This actually
fits very well in the existing IGP architecture - node capabilities are
never per topology. At the end you only have a single label block on a
device. You can partition it in many ways, but the block is just one.
>
> [Peter] The SR architecture from the very beginning assumed per
> MTID/algorithm SID, not per MTID/algorithm SRGB and IGP encoding has
> been designed with that in mind.
>
> Can you point to a place in the architecture document where it
says that
> SIDs are only "global" per MTID/algorithm and/or that SRGBs are
> per-algorithm?
form draft-ietf-spring-segment-routing-04.txt:
"SR Global Block (SRGB): local property of an SR node."
"IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP
segment attached to an IGP prefix.
Above makes it clear to me that SRGB has a per node property and is
advertised by IGP as such. Prefix-SID is a prefix property and as such
can be advertised per MTID topology, as any other prefix attribute.
IGP encodings for OSPF and ISIS have been designed by a team of people
from multiple vendors and some of them contributed to the SR
architecture document as well - the fact that we designed the IGP
encoding the way it is clearly indicates what was the common
understanding of the SR architecture.
We can surely improve the wording in the SR architecture document if you
feel so.
>
> [Peter] If you add MTID and algorithm in SRGB as well, you end up
with
> the MTID and algorithm fields at two different TLVs for the same
> topology - inside SRGB and inside the Prefix SID sub-TLV, which is
> clearly redundant.
>
> I don't really understand what problem is being stated above.
the problem is that you create an overlap, where both SRGB and
prefix-SID would be carrying the same values. I suppose you agree that
we do not need these fields to be associated with both SRGB and SIDs.
>
> [Pushpasis] I am trying give both options to a operator (i.e. Single
> SRGB with per-topology SID-index as well as single SID-index with
> per-topology SRGB). Depending on which one the operators prefer,
one of
> them becomes redundant.
>
> [Peter] I'm not sure we want to advertise redundant data to allow
more
> configuration flexibility. From both architecture and encoding
> perspective it's preferable to pick single approach.
>
> I see this issue differently. We already allow (but do not
require) a
> different SRGB to be assigned to each instance of each routing
> algorithm;
no, we don't. SRGB scope is IGP instance. There is no algorithm there.
> but a different SRGB cannot be assigned to each topology of a
> given instance of a given algorithm. This means there are already
> multiple ways of assigning SIDs/SRGBs, with some restrictions
that don't
> seem to make much sense.
>
> Also I don't think it's a good trade-off to limit configuration
> flexibility in order to simplify an encoding.
>
> [Peter] please bear in mind that there are implementations out
there in
> the field with the existing encoding.
>
> I'm sure any changes could be made in a backwards compatible manner.
to change the existing encoding one would need a strong reason. I do not
see anything which can not be done with the existing encodings.
thanks,
Peter
>
> [Peter] If you move the MTID/algorithm fields from Prefix SID to
SRGB,
> what is the MTID/algorithm fields in prefix SID used for? Having the
> MTID/algorithm fields in both Prefix SID and SRGB would be
redundant and
> confusing.
>
> Tthe encoding could be designed to not only be backwards
compatible, but
> also to give unambiguous semantics to all combinations.
>
>
>
>
>
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
