Hi Les, > Putting the Inside Node TLV aside for the moment, it would seem to me to be > advantageous (in a modest way) to have all information relating to Area Proxy > contained in one advertisement. Using Router Capabilities TLV would > accomplish that.
I agree that the information should be contained, this is why we opted to put it all into one top level TLV. Recall that only the Area Leader is advertising the Area Proxy TLV, while all inside nodes need the capability. > Your concern about “burdening” the Router Capabilities TLV seems unwarranted. Given that we have 64k top level code points, I’m equally confused about your concern. > Multiple Router Capability TLVs are allowed (indeed even required to support > different flooding scopes) – so TLV space is not limited. I expect that we will have numerous bug reports when we start to cross the TLV boundary. I’m not in favor of pushing this. > Returning to Inside Node TLV, I share your concern about advertising Router > Capabilities TLV in pseudo-node LSP. But what does it mean to advertise the > Inside Node TLV in a pseudo-node LSP? It’s a clear indication that the pseudonode is intended to be inside. > Presumably you need some capability indicator because even on boundary > circuits the DIS will use the native systemid rather than the proxy systemid > and therefore you cannot tell based on pseudonode-id alone what type of > circuit this is. Correct. The DIS would have a very difficult time using the proxy systemid and assigning a unique circuit id for the pseduonode. Some other system on the other side of the area could be making exactly the same choice, leading to a collision. Thus, it seems simpler to use the native system id and explicitly signal that the pseudonode is inside. I’ve become a pretty big fan of explicit signaling, as it’s more robust. > Would this argue for advertising “this is a boundary circuit” in pseudo-node > LSPs for boundary circuits rather than advertising “inside” on all inside > pseudo-nodes? You could do it that way. It inverts the semantics and inverts the deployment. Logically, it should have the same effect. However, it then is seen by outside nodes. Since they need not support Area Proxy, this seemed like a riskier approach, thus we opted for marking inside pseudonodes. > And do you need the “boundary circuit” indication in L2 IIHs (and perhaps P2P > IIH as well??) as protection against improperly forming adjacencies on > boundary circuits? Not required if there is consistent configuration. All inside nodes will be using the proxy system ID in their IIH. If a node is inconsistently configured, then it is difficult to prevent at least one side from trying to form the adjacency. > Regarding the Area SID advertisement, I take the point that this concept > might be useful more generically, but as it is key to have the correct scope > for the SID, it is hard to see how the advertisement could be used apart from > the context (Area Proxy in this case). So advertising it separately doesn’t > seem useful. To me, it seems like it is a useful anycast SID anytime there is hierarchy present. It seems somewhat useful to be able to create paths that say things a bit more abstractly: Take the path from San Francisco, through Los Angeles, Dallas, St. Louis, and then Atlanta to get to Washington. This would allow higher level TE without worrying about more specific details. This also opens up the possibility of hierarhcical TE, which we may wish to explore for the sake of scalability. > Regarding consistent SRGBs, you might find > https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/ > <https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/> > worth reading as something attempting to address a similar problem. It isn’t > easy. Thank you for the pointer, I will review. I appreciate your comments. I wish that they had been much earlier in the process. I will take them much more seriously if and when the document is adopted by the WG. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr