Hi Acee In-line
On Thu, Jul 29, 2021 at 4:24 PM Acee Lindem (acee) <acee= [email protected]> wrote: > Speaking as WG member: > > > > Authors, > > > > I think this draft is still flawed. Regarding the terminology, I don’t > think it should refer to passive interfaces at all since they aren’t > referenced in protocol documents. Rather, you should use stub-link > consistently – including the title. However, I don’t think this makes any > difference as I think you need to “go back to the drawing board”. > > Gyan> Agreed. We will change any references to passive to stub. > > Why do other routers in the domain need to know the link if it isn’t > connected to any other routers? The stub-link is an artifact of OSPFv2 used > to advertise local prefixes. As you noticed, it was removed in OSPFv3 and > local prefixes are advertised in Intra-Area-Prefix LSAs (and > E-Inter-Area-Prefix-LSAs). I really think you are trying to advertise > attributes of a prefix and not a link. In fact, in OSPFv3 there is no > address associated with the link – I see you have attempted to remedy this > by adding a sub-TLV to advertise the prefix associated with the link ;^). > So, now this local prefix will be advertised two different ways? > > Gyan>(We did remedy as you asked) Per yours and I believe Peters a d > others recommendation with OSPFV2 update RFC 7684 change from fixed format > LSA to TLV based similar to OSPFV3 RFC 8362 which the other big change was > the breakout of “topological” construct from the prefix creating separate > router links LSA for “topological” and prefix LSA for prefixes. As the > passive or stub concept as you have reiterated to the authors is really > topological and of prefix based to use router links and not router prefix > to add the new stub TLV so that is what we did for both OSPFV2 and OSPFV3 > and added new top level stub TLV for ISIS. > > Specifically, what is BGP controller going to do with the stub link > advertisement that it couldn’t do with a prefix advertisement? Also, why > can’t the AS boundary router report the inter-AS prefix via BGP-LS? The > other routers in the IGP domain have no use for this information. > > Gyan> From a use case perspective the goal is to make this new stub TLV > generic so it can be used for any use case where you have a stub LSA that > is advertised that can be tracked by the PCE controller for the NB BGP-LS > building of the topological graphs and being able to distinguish any stub > nets from transit nets with neighbors. > > What is the use-case for knowing that a prefix is associated with a > loopback? We already have the N-Flag (Node) for prefixes… What is your > loopback use case? > > Gyan> When NBI BGP-LS builds the topological graphs it’s any stub link > which could be inter-as or loopbacks or any interfaces so they can be > differentiated when the LSDB is build for the TEDs database. > > Also, what is the Vlan interface use case? What possible use could other > routers in the domain have for this information? > > Gyan> I believe vlan is just another example but it’s really any interface > that is a stub link with no neighbors can be treated differently by the NBI > BGP-LS, when the topological graph is built. > > Thanks, > Acee > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
