Eric,
please see inline:
On 8/25/15 20:17 , Eric C Rosen wrote:
On 8/25/2015 9:58 AM, Acee Lindem (acee) wrote:
It appears there are varying opinions on deployment models. A global SID
is used as an offset into a node’s local SRGB(s) in order to derive the
ingress label used for the associated prefix (or other construct) for
that node. There are two opinions on deployment. The first model is that
the global SID is, in fact, global and you would use a different SID if
you want to advertise a different segment, i.e., forwarding instruction.
The second is that the global SID is not really global and maps to a
different segment dependent on the protocol instance or topology. Of
course, I favor the first model but wanted to hi-light the point of
contention.
So I guess the primary question is: should the choice of deployment
model be left to the operator, or should the architecture/signaling
mandate one deployment model over the other?
My interpretation of the architecture is that it intends the first
deployment model, with a global SID (SID maps globally to single
forwarding instruction) and an SRGB that has node-wide scope.
However, as SPRING has no control plane of its own, it relies on the IGP
to signal the SRGB. As a result, if there are multiple IGP instances,
it is possible for a single node to signal multiple SRGBs. This means
that the SRGB signaling is NOT per-node, but (at least) per IGP instance.
right there is no problem with per IGP instance SRGB, we all agreed that
it is valid and it is supported.
The architecture could require all the IGP instances on a given node to
signal the same SRGB. The discussion of the SRGB in the yang model
shows pretty clearly that some people thought that this is a
requirement, and some thought that it is not. I think that discussion
also shows that the overall feeling of the WG is that this requirement
should not be imposed, and that it should be allowable for different IGP
instances to advertise different SRGBs. Of course, this now allows
Acee's second deployment model.
not really. Per IGP SRGB still fits well in first model.
And once we allow a different SRGB for each IGP instance, I don't
understand why we wouldn't allow a different SRGB for each topology. I
haven't heard a technical reason for not allowing this; the only real
argument has been "but it's too late to make any changes, even if they
are backwards compatible".
the point I'm trying to make is that there is no functionality in the
second model which can not be supported with existing first model. In
such case I do not see any good reason to change the architecture and
mess around with the existing IGP encoding.
I think everyone understands that a scheme that required multiple
unrelated SIDs to be provisioned for each prefix would be a burden for
the operators. Peter has made a proposal in which the provisioning
process assigns one prefix-SID to a prefix, where that prefix-SID
represents the forwarding instruction for that prefix in the default
topology. Then prefix-SIDs for additional topologies can be
automatically assigned by adding a topology-specific offset to the
default-topology prefix-SIDs. However, the topology-specific offset
sounds a lot like an SRGB. I don't really see what this proposal adds
other than complexity.
why do you believe it adds complexity? Why is provisioning of the offset
any more complex then provisioning the SRGB? Actually it is the same,
the only difference is what is advertised.
Further, if one has 1000 prefixes and adds a new topology, advertising
1000 new prefix-SIDs in order to avoid the need to advertise a single
new SRGB does not seem like a very good trade-off.
prefixes are advertised in each topology anyway, so adding a single
sub-TLV for prefix in each topology is certainly not a significant overhead.
thanks,
Peter
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
