Re: [Lsr] Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy

["Les Ginsberg (ginsberg)" <[e-mail]>]

Tony –

We don’t have to resolve this now.
One of my motivations for sending this was related to Early Allocation of code points. Since you have already asked once, I am assuming that if WG adoption is achieved it will be swiftly followed by an early allocation request – and as one of the Designated Experts I wanted to share my concerns sooner rather than later.

A few more responses inline.

From: Tony Li <[e-mail]> On Behalf Of [e-mail]
Sent: Saturday, June 20, 2020 5:13 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: Comments on Requested Codepoints for draft-li-lsr-isis-area-proxy


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.

[Les:] My proposal does not alter what information is sent by Area leaders/non-Area leaders – just the container in which the information appears.


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.

[Les:] Today, we only have 255 top level codepoints.
64K codepoints will only become available when the industry moves to RFC 7356 based implementations and includes the 16 bit TLV Type/Length option.
While I would obviously like to see this happen, as it isn’t backwards compatible I expect we are still some years away from a “tectonic shift”.
And your draft does not propose moving to RFC 7356 as part of the feature (and I am not suggesting that it should).

At least part of the reason we still have sufficient available top level code points is that we do our collective best to use them judiciously.


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.

 [Les:] We already enough info to advertise that one Router Capability TLV is not enough. Implementations that cannot handle multiple Router Capability TLVs are already busted.
Area Proxy by itself won’t force this to be exposed.

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.

[Les:] Yes, I understand  and agree with your choice. There is no good way to manage the pseudo-node ID space in a distributed manner.


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.

[Les:] My point was largely motivated by the statement in the draft:

“Area Proxy Boundary multi-access circuits (i.e.  Ethernets in LAN
   mode) with multiple Inside Edge Routers on them are not supported.”

So it seems advantageous to be able to prevent this from happening – which requires some signaling on the circuit in question.


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.

[Les:] Yes – the key point here is “consistent configuration”. It seems useful to be able to detect/report mismatched configurations – which is why I thought advertising the new capability explicitly could be helpful.
Trying to form an adjacency that shouldn’t be formed isn’t a significant problem. The more significant problem is if the adjacency were to come up when it should not.


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.

[Les:] Again, I am not arguing that point. I am saying for this to be useful requires knowing what set of routers are using the advertisement – which requires the association with IER capability for Area Proxy.

   Les


Regarding consistent SRGBs, you might find 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