Hi Acee,
However, it still may be simpler operationally to advertise a Global Prefix-SID for a locally attached subnet comprised of nodes offering a particular service.
I don't think I suggested anything that would prevent one from advertising a domain-wide prefix-SID for a locally attached subnet.
With respect to the Originator SRGB, I never could fully appreciate the advantages of advertising it.
That suggests that you don't really see the use case for it. I believe the intended use case is the following. Suppose node S has a packet to send to prefix D, and S knows (through some magic) that it wants the packet to traverse nodes A, B, and C (i.e., to follow the path S-A-B-C-D), even though this is not the default shortest path from S to D. Let's also suppose that this is a loose source route, i.e., that A is not adjacent to B, B is not adjacent to C, and C is not adjacent to D. In order for S to force a packet through this loose source route, it is necessary for S to push labels on the packet in the following order: 1. Push C's label for D. 2. Push B's label for C. 3. Push A's label for B. 4. Push whatever label will get the packet from S to A. To compute label 1 above, S must know (a) C's SRGB and (b) the (global) prefix-SID for D. To compute label 2 above, S must know (a) B's SRGB and (b) the (global) prefix-SID for C. To compute label 3 above, S must know (a) A's SRGB and (b) the (global) prefix-SID for B. If A, B, and C, each originates a BGP UPDATE with its own loopback address as prefix, then each can advertise its own SRGB by attaching a Prefix-SID attribute to the UPDATE, and specifying its SRGB in the Originator-SRGB field of the Prefix-SID attribute. I think all the use cases for Originator-SRGB will be like this; (a) tunnel to the node whose SRGB it is, and (b) use that node's SRGB to figure out what label to push beneath the labels that get you to the tunnel endpoint. I don't see how you can do this unless you know the address of the node to which you are tunneling, and unless you know that node's SRGB. If you're not trying to do something like this, there is no need for the Originator Sub-TLV. In this example, one could imagine that A, B, C have the same SRGB, and that there is a prefix covering the addresses of A, B, and C. In that case, it might make sense to advertise the Originator-SRGB in a route whose to the covering prefix. So I agree (now) that the prefix need not be a /32 or /128. Naturally, the originator SRGB sub-TLV is just one of several possible ways of allowing a node to advertise its SRGB. Another way for a node to advertise its SRGB would be to use the segment routing extensions of BGP-LS. However, there are scenarios in which BGP-LS is not present, but BGP-LU is in use. There's also a completely different way of figuring out the labels for the traffic engineered path, using the EPE extensions of BGP-LS. Those extensions allow a BGP speaker to advertise a (locally significant) adjacency-SID for each of its BGP neighbors. Since those labels are locally significant, you don't need to know the SRGBs of the transit nodes. But that's a different use case.
If you advertise an Originator SRGB, it implies that there nodes with differing SRGBs in the BGP Routing Domain. If this is the case, there is a very good chance that nodes receiving the Prefix-SID Attribute with the Originator SRGB will not have the same SRGB and will not have the Originator-SRGB[label-index] label available for local allocation.
Right. In the use case I described above, the Originator-SRGB of a particular node is used only to compute label values for the node whose SRGB it is. No one else uses it for local label allocation.
I can’t really see what different it makes whether or not it is a host prefix or whether you can ascertain the node to which the SRGB belongs.
Please see the use case described above.
It seems that the key constraint is that the label-index and the SRGB came from the same node and this is always the case.
Now it's my turn to say that I don't understand the use case you have in mind ;-) If all you know is that the SRGB and the Prefix-SID sub-TLVs were created by the same node, I don't see what good it does you to know the SRGB. Eric _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
