Hi Aijun, I think that would be an excellent idea. Thanks, Acee From: Aijun Wang <[email protected]> Date: Monday, August 16, 2021 at 9:17 PM To: Acee Lindem <[email protected]> Cc: 'Aijun Wang' <[email protected]>, 'Gyan Mishra' <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [Lsr] [Stub-Link-Attributes] Comments on "Passive Interface Attribute" - draft-wang-lsr-passive-interface-attribute
Hi, Acee: How about the following considerations: 1. For OSPFv2/v3, we can put the proposed TLVs within in “Inter-AS-TE-v2/v3 LSA”(for OSPFv2/v3) as defined in RFC5392. 2. For ISIS, we can put them under “Inter-AS Reachability TLV”, as defined in RFC5316. Comparing with other proposals, the above solutions may be more easy to implement and deployment, and does not influence the core SPF computation. Best Regards Aijun Wang China Telecom From: Acee Lindem (acee) <[email protected]> Sent: Tuesday, August 17, 2021 4:15 AM To: Aijun Wang <[email protected]> Cc: Aijun Wang <[email protected]>; Gyan Mishra <[email protected]>; [email protected]; [email protected] Subject: Re: [Lsr] [Stub-Link-Attributes] Comments on "Passive Interface Attribute" - draft-wang-lsr-passive-interface-attribute Hi Aijun, From: Aijun Wang <[email protected]<mailto:[email protected]>> Date: Sunday, August 15, 2021 at 12:17 AM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: Aijun Wang <[email protected]<mailto:[email protected]>>, Gyan Mishra <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] [Stub-Link-Attributes] Comments on "Passive Interface Attribute" - draft-wang-lsr-passive-interface-attribute Hi, Acee: The information that we want to distribute are the attributes of the stub link, not the associated prefixes. The associated prefix is just one attributes of them. The Stub-Link TLV proposed in this draft is different from the normal Link TLV. It will and should not influence the core SPF calculation, whose aim is protocol independent. When router receive these Stub-Link TLVs, which are in the Router LSA, they should only use it for cases mentioned in this draft, or other applications that differ from the SPF calculations. I think such considerations does not conflict with the purpose of RFC5340. Or, we can consider this issue from other viewpoints: there are emerging applications that needs to use the characters of these stub-links, we should re-examine the design considerations made in 14 years ago. And, for OSPFv2/v3, there are some ways to correlate the stub link interface and its associated prefixes(via the interface ID) if we do not put them together. But for ISIS, I do not find the correlation method. For consistency and simplicity, I propose to keep the current encoding format. It is also a bit strange that let the attributes(for example, bandwidth, delay, reserved resources etc.) associated with the prefixes, and at current there is no solution if different applications want to define different values for these attributes(ASLA). Will we define ASPA(Application Specified Prefixes Attributes) then? If you are proposing to advertise links and their attributes for links that are outside of the IGP topology, you should not advertise them with the same OSPF LSAs or IS-IS TLVs as the links that have meaning to the IGPs. Also, this would beg the question as to why you are not using IS-IS Gen App (RFC 6823) and OSPF Transport Instance to advertise this information. If this is where you are going, I don’t believe you have a strong enough use case to justify specification, let alone the development and deployment. Thanks, Acee Aijun Wang China Telecom On Aug 15, 2021, at 03:24, Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: Speaking as WG Member and longstanding steward of the OSPF protocol: Hi Aijun, As I stated during the LSR meeting, one of the main changes between OSPFv3 and OSPFv2 is that the addressing semantics are removed from the router and network LSAs. Refer to section 2.2 in RFC 5340. o Router-LSAs and network-LSAs no longer contain network addresses, but simply express topology information. See Section 2.8 for details. The OSPFv2 stub link was somewhat of a hack to advertise local prefixes and it was removed in OSPFv3 as prefixes are advertised in separate LSAs. We certainly don’t want to revert this behavior and definitely not for a questionable use case outside the OSPF protocol itself. Additionally, the example you state of the prefixes already being advertised ambiguously is not flawed in the that the Link-LSA and Intra-area-prefix-LSA are advertised at different flooding scopes (link-scope versus area-scope). The attributes that you want to convey throughout the area domain are relevant to the prefix itself and not a link that has any topological significance to OSPF. This should be reflected in the draft and the advertisement should be proposed for prefixes as opposed to adding the stub-link concept. Hence, I don’t think there should be an adoption call for this document in its current form. Thanks, Acee From: <[email protected]<mailto:[email protected]>> on behalf of Aijun Wang <[email protected]<mailto:[email protected]>> Date: Saturday, July 31, 2021 at 8:48 AM To: Aijun Wang <[email protected]<mailto:[email protected]>> Cc: Acee Lindem <[email protected]<mailto:[email protected]>>, Gyan Mishra <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] [Stub-Link-Attributes] Comments on "Passive Interface Attribute" - draft-wang-lsr-passive-interface-attribute 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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: Hi Gyan, See brief inlines. From: Gyan Mishra <[email protected]<mailto:[email protected]>> Date: Thursday, July 29, 2021 at 10:24 PM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
