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 

A few more responses inline.

From: Tony Li <> On Behalf Of
Sent: Saturday, June 20, 2020 5:13 PM
To: Les Ginsberg (ginsberg) <>
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 

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 

[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 

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 

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 

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.


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


Lsr mailing list

Reply via email to