Hi, All: I have uploaded the updated draft with the new name “draft-wang-lsr-stub-link-attributes” at https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/, which replaces the previous passive interface draft.
Any comments are welcome. We think it is ready for WG adoption call. Aijun Wang China Telecom > On Jul 31, 2021, at 10:35, Aijun Wang <[email protected]> wrote: > > Hi, Acee: > > Regarding to your comments on the meetings that where to put the attributes > of these stub-link attributes, I had reviewed again the previous discussions > on the mail list. Please see it at > https://mailarchive.ietf.org/arch/msg/lsr/LbsiUl9iL_9zTXnxtuAnKVpfmGs/. Then > putting it into link related attributes is more reasonable. > > Regarding your concerns for the associated prefixes to be advertised in > different places, I checked also > https://datatracker.ietf.org/doc/html/rfc8362#section-3.7 and we can see for > Intra-Area-Prefix TLV, it can also be included in two different places. The > redundancy information has no influence for any other aspects, just used for > easy correlation. > > And, based on the discussion along with 5G edge use case and the ASLA > attributes(please see > https://mailarchive.ietf.org/arch/msg/lsr/0Lk8IPxsD1BJYT9D-NcRQJEnwHU/ ). It > is then more reasonable to put these attributes into link related TLV, that > is, the newly defined Stub-Link TLV/Sub-TLV. > > If there is no other comments/argues on this draft, we will update the draft > in recent days, change the name to “draft-wang-lsr-stub-link-attributes” and > ask for WG adoption. > > Thanks in advance. > > Aijun Wang > China Telecom > >> On Jul 31, 2021, at 06:45, Aijun Wang <[email protected]> wrote: >> Hi, Acee: >> >> Thanks for your comments. >> Please see the replies inline. >> >> Aijun Wang >> China Telecom >> >>> On Jul 31, 2021, at 01:00, Acee Lindem (acee) <[email protected]> wrote: >>> >>> Hi Gyan, >>> >>> See brief inlines. >>> >>> From: Gyan Mishra <[email protected]> >>> Date: Thursday, July 29, 2021 at 10:24 PM >>> To: Acee Lindem <[email protected]> >>> Cc: "[email protected]" >>> <[email protected]>, "[email protected]" >>> <[email protected]> >>> Subject: Re: [Lsr] Comments on "Passive Interface Attribute" - >>> draft-wang-lsr-passive-interface-attribute >>> >>> >>> Hi Acee >>> >>> In-line >>> >>> On Thu, Jul 29, 2021 at 4:24 PM Acee Lindem (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. >>> I’m glad you didn’t modify the base LSAs. However, my question is why the >>> entity you are trying to describe isn’t just a local prefix – why do we >>> need to create a stub-link? >> >> [WAJ] There are other attributes need to be associated and advertised with >> these stub links. Please refer to the discussion at >> https://mailarchive.ietf.org/arch/msg/lsr/0Lk8IPxsD1BJYT9D-NcRQJEnwHU/ for >> 5G edge computation use case. >> >>> >>> 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. >>> I don’t see why this attribute can’t be associated with a prefix and why we >>> need a link. Furthermore, I don’t see any of the types as being useful >>> other than inter-AS. And for inter-AS, it can be advertised in BGP-LS. >>> Clearly, if there is an inter-AS interface, the router is running BGP. >> >> [WAJ] As stated above, there are other attributes that should be associated >> with the stub links. There are also other use cases for theses information >> on the controller. For example, the controller can deploy network boundaries >> security policy once it knows which interfaces are facing the external world. >> It can also release the operator from deploying BGP-LS on every border >> router for inter-AS use case. >> The 5G edge computation that described in >> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ is >> another use case for these stub links on IGP routers. >> >>> Thanks, >>> Acee >>> >>> >>> Thanks, >>> Acee >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >>> -- >>> >>> >>> Gyan Mishra >>> Network Solutions Architect >>> Email [email protected] >>> M 301 502-1347 >>>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
