Hi, Christian: Tony’s explanations are correct. The proposed TLV is mainly one container, in order to include the related attributes of the Stub-Link, not the configuration. Actually, such proposal can reduce the configuration headaches(no matter via NMS or Manual) when you want to do some kind of inter-AS TE.
The motivation we do this are for controlling , or optimization or engineering of the traffic in/out these stub links. It may have some relation to other AS(inter-AS scenarios), or the application server(5G Edge Computation scenarios), or only the AS boundary(security control scenarios) Aijun Wang China Telecom > On Jan 13, 2022, at 10:32, Christian Hopps <cho...@chopps.org> wrote: > > > >> On Jan 12, 2022, at 9:03 PM, Tony Li <tony...@tony.li> wrote: >> >> >> 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. > > The thing about the TE information is that it's being used to make live > routing decisions (i.e., in a CSPF). We have pretty consistently denied > requests to ship generic router configuration around using the IGPs. > > Consider the case of configuring an inter-AS bgp connection, for that I'm > imagining configuring a "BGP peer" service in my NMS. Part of that service is > going to specify the neighbor AS and perhaps the router (or routers) to > connect over. The NMS is going to look inside it's router information DB and > use that information to construct the configurations for the service. If I > tell it to deploy that service, it's going to then push those generated > configuration files out to the affected routers, etc. > > I'm not seeing any need yet for this information to be shipped around in the > IGP. > > Thanks, > Chris. > >> >> T >> > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
