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

Reply via email to