Hi Eric, On 11/18/15, 10:55 AM, "Eric C Rosen" <ero...@juniper.net> wrote:
>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. Okay - I understand the motivation now. The Originator-SRGB TLV is simply a mechanism for node to advertise its local SRGB to a controller or other BGP speaker that will construct segments. I now recall the non-concluded discussion on the IDR list with respect to this requirement. Thanks, Acee > >> 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
