> On Jan 12, 2022, at 5:35 PM, Aijun Wang <[email protected]> wrote: > > Hi, Christian: > > Aijun Wang > China Telecom > >> On Jan 13, 2022, at 04:19, Christian Hopps <[email protected]> wrote: >> >> Doesn't this reduce to: "The operator configures one of their routers with >> an IGP "passive" link config, and then uses this IGP extension so their >> other routers (in the same AS) can discover that configuration"? > > [WAJ] Yes, this is same behavior for the normal link within IGP. > The difference is that we need not configure the remote end information(in > numbered AS boundary interface scenarios) again. > The advertising information within the IGP is only information about its own.
I'm having a little trouble fully understanding what you're saying here. However, I think what is being done is the user configures one router (e.g., configures "isis passive" on "interfaec Foo0"), and the fact of that configuration is then transmitted inside the IGP. Other routers in the same domain then see and act on this configuration. That is exactly what a network management system is for. This can and should all be done with a network management system not the routing protocol. Thanks, Chris. [as wg member] > > Aijun Wang > China Telecom > >> >> Thanks, >> Chris. >> [as wg member] >> >> >>> On Jan 11, 2022, at 8:51 AM, Aijun Wang <[email protected]> wrote: >>> >>> Hi, Christian: >>> >>> The benefit of the proposed solution is that for inter-AS scenarios, it can >>> accomplish the automatic pairing for the two ends of inter-AS link without >>> the explicitly configuration for the remote end information. >>> In other scenarios, it can also contain useful information for the edge >>> computation services, aid the operator know exactly the boundary of the >>> network and apply special security policy at such stub link if necessary >>> etc. >>> >>> I have updated the draft today in order to address the concerns for >>> unnumbered interface and sub-TLV hierarchy that raised by Peter and Les. >>> Please review it if there exists any other concerns. >>> >>> Thanks. >>> >>> >>> Aijun Wang >>> China Telecom >>> >>>>> On Jan 11, 2022, at 20:55, Christian Hopps <[email protected]> wrote: >>>> >>>> >>>> Peter Psenak <[email protected]> writes: >>>> >>>>> Aijun, >>>>> >>>>>> On 05/01/2022 16:20, Aijun Wang wrote: >>>>>> [WAJ] The above remote information must be configured manually on the >>>>>> local >>>>>> device. It is paired by manual. Thinking there are many links among the >>>>>> ASBRs, >>>>>> would you like to configure them manually for every remote ends on each >>>>>> link? >>>> >>>> No one with large scale networks, and/or routers with lots of links is >>>> doing any sort of manual configuration. It seems to me that I keep seeing >>>> this mentioned as justification for changes or extensions to the IGPs. It >>>> is not reasonable justification b/c no-one is doing it. >>>> >>>> I think it would be very useful if manual configuration or the assumption >>>> that we need to make that less painful, stopped being brought up so we can >>>> focus on other reasonable justifications (or lack thereof :) >>>> >>>> Thanks, >>>> Chris. >>>> [as wg member] >>>> >>>> >>>>>> The prefixes that associated with the stub link can assist to accomplish >>>>>> this task automatically. >>>>> >>>>> If the ISIS/OSPF adjacency is not formed over the link, you need to >>>>> manually >>>>> configure remote endpoint parameters. Defining a new TLV is not going to >>>>> make >>>>> any difference. >>>>> >>>>> Using the local subnet information for identifying two endpoints of the >>>>> same >>>>> link does not sound appealing to me. >>>>> >>>>> We have link local/remote IDs (and IP addresses) to pair the two >>>>> endpoints of >>>>> the link in both OSPF and ISIS. We do not need another mechanism for the >>>>> same. >>>>> In addition, what you propose does not work for unnumbered links. >>>>> >>>>> I don't see a need for the new stub-link advertisement. >>>>> >>>>> thanks, >>>>> Peter >>>>> >>>>> >>>>> _______________________________________________ >>>>> Lsr mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/lsr >>>> >>> >> > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
