Chris, > This isn't the same as TE information which can be/is based dynamic values on > the router.
Are you sure? First, much of the TE information that we have distributed is static (administrative group, SRLG, etc.). The dynamic part has been bandwidth reservation. That still seems applicable to inter-AS stub links, even tho Aijin hasn’t articulated that yet. It does seem inevitable, again assuming I understand the use case. > I'm pretty sure that it isn't even using the 2-way connectivity check. It's > literally just saying "Router A has a stub link B (i.e., it has the config > 'isis passive' on it)". As the draft has it, you’re correct. However, there’s all that undefined subTLV space just begging for TE information. The current ‘link type’ information seems somewhat pointless if it isn’t intended to be a item for TE consideration. > That infomration is already a part of an operators NMS b/c that NMS is what > generated that router's configuration and stuck it on that router in the > first place. That same NMS is going to be configuring the other router that > would be looking for that "stub link" information in the IGP. Unless I've > mis-understood something here, the proposoal is literally just pushing static > configuration details around inside the IGP. Agreed 100%. But it’s also what we do today with much of the static TE information. Again, there’s precedent. T
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
