[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024)
Hi, Acee: 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee Lindem 发送时间: 2024年1月16日 6:44 收件人: Aijun Wang 抄送: Christian Hopps ; Liyan Gong ; Yingzhen Qu ; lsr ; lsr-chairs 主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024) Speaking as WG member: Hi Aijun, I know you have gotten some of your co-authors on other drafts and colleagues to parrot your arguments in favor of this draft. However, you still have not addressed my comments. Why is better to advertise the link as stub link and surmise that it is an inter-AS link than it is to advertise this inter-AS status directly? Presumably, if you advertise this inter-AS link, you’re going to have routes using the link. If you have routes using the link, you’d think that you’d know the AS of these routes and this is not “inefficient” as you characterize it. It would seem if you going to use this link for intra-AS TE, you should know the AS to which this is directed. I don’t see why your encoding is any more efficient. [WAJ]: The requirements for inter-AS TE and the requirements for inter-AS topology recovery are different. The key difference is that the previous covers only some of the inter-AS links, but the latter must cover all of the links between the AS. Then find some efficient way to solve the inter-AS recovery problem is necessary. See inline. On Jan 15, 2024, at 09:02, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote: Hi, Chris: The first adoption call focus on the A.1 use case(figure 1), not cover all of the use case that listed in A.1-A.3 For A.1(Figure 1) use case, previous discussions focus on mainly the benefits of the configuration simplification, which you emphasize that IGP does not mainly for such work.wor The use cases in A.2 and A.3 aren’t applicable. For anycast servers, why you this have anything to do with stub links? More protocol intuition? We have mechanisms advertise anycast prefixes - arguing that this a use case for stub links is just wrong. As for A.3, how does this even work? Why couldn’t this just be done on the prefix to which BGP routes resolve (as it is done today)? [WAJ]:The procedures for A.2 and A.3 are similar: the receiving router can select the optimal forwarding path(or network exit), based on the attributes of the stub links. Currently, all the selections are based on the characteristics/attributes of internal links. OK, now let us consider other issues of the existing solutions——how to get the related information automatically and error-proofing? RFC9346 and RFC 5392 mentioned all such challenges, they even propose to use BGP to cross verify such information, which is still on the imagination stage. How is what you are proposing better? Since you are ASSUMING that a stub link connects another AS, it is even more error-prone. [WAJ] To rebuild the inter-as topology, we don’t need the above information from other sides, thus reduces the error-prone chances. What we assuming is that the stub link should share the same subnet, we can connect the two ends of the stub link automatically based on such assumption. If there is some errors for the shared prefix, the two ends can’t communicate with each other at all. Thanks, Acee Then, if there is solution can bypass such requirements, should we consider it then? Especially from the deployment viewpoint of the operator? Together with the above points, the proposed solution can cover other use cases, which are not discussed throughly in previous adoption call. If one proposal can simply the deployment requirements of existing solution for some cases(A.1 Figure 1 and A.3), can solve some case that existing solution can’t(A.1 Figure 2 and A.2) should we accept it then? We can discuss throughly on the above statements then for the second adoption call, pass the configuration simplification arguments. Aijun Wang China Telecom On Jan 15, 2024, at 20:19, Christian Hopps mailto:cho...@chopps.org> > wrote: On Jan 15, 2024, at 06:27, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote: Hi, Chris： There are significant changes from the last adoption call(version 02) to the current version(version 08). Then I doubt the valid information from the previous discussions. For example, there is no concrete use cases description in the previous version, which is provided in the appendix A.1-A.3 of current version. [As WG member] The original use case may not have been listed in previous document, but it was discussed very thoroughly during the adoption call. It did not convince the WG to adopt the first time, b/c the WG felt existing solutions were sufficient -- nothing changed with respect to this for this second adoption call that I see. Thanks, Chris. There are also the updates for the protocol extension, which absorbs the
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024)
Speaking as WG member: Hi Aijun, I know you have gotten some of your co-authors on other drafts and colleagues to parrot your arguments in favor of this draft. However, you still have not addressed my comments. Why is better to advertise the link as stub link and surmise that it is an inter-AS link than it is to advertise this inter-AS status directly? Presumably, if you advertise this inter-AS link, you’re going to have routes using the link. If you have routes using the link, you’d think that you’d know the AS of these routes and this is not “inefficient” as you characterize it. It would seem if you going to use this link for intra-AS TE, you should know the AS to which this is directed. I don’t see why your encoding is any more efficient. See inline. > On Jan 15, 2024, at 09:02, Aijun Wang wrote: > > Hi, Chris: > > The first adoption call focus on the A.1 use case(figure 1), not cover all of > the use case that listed in A.1-A.3 > For A.1(Figure 1) use case, previous discussions focus on mainly the benefits > of the configuration simplification, which you emphasize that IGP does not > mainly for such work.wor The use cases in A.2 and A.3 aren’t applicable. For anycast servers, why you this have anything to do with stub links? More protocol intuition? We have mechanisms advertise anycast prefixes - arguing that this a use case for stub links is just wrong. As for A.3, how does this even work? Why couldn’t this just be done on the prefix to which BGP routes resolve (as it is done today)? > > OK, now let us consider other issues of the existing solutions——how to get > the related information automatically and error-proofing? RFC9346 and RFC > 5392 mentioned all such challenges, they even propose to use BGP to cross > verify such information, which is still on the imagination stage. How is what you are proposing better? Since you are ASSUMING that a stub link connects another AS, it is even more error-prone. Thanks, Acee > > Then, if there is solution can bypass such requirements, should we consider > it then? Especially from the deployment viewpoint of the operator? > > Together with the above points, the proposed solution can cover other use > cases, which are not discussed throughly in previous adoption call. > > If one proposal can simply the deployment requirements of existing solution > for some cases(A.1 Figure 1 and A.3), can solve some case that existing > solution can’t(A.1 Figure 2 and A.2) should we accept it then? > > We can discuss throughly on the above statements then for the second adoption > call, pass the configuration simplification arguments. > > > Aijun Wang > China Telecom > >> On Jan 15, 2024, at 20:19, Christian Hopps wrote: >> >> >> >>> On Jan 15, 2024, at 06:27, Aijun Wang wrote: >>> >>> Hi, Chris： >>> >>> There are significant changes from the last adoption call(version 02) to >>> the current version(version 08). Then I doubt the valid information from >>> the previous discussions. >>> >>> For example, there is no concrete use cases description in the previous >>> version, which is provided in the appendix A.1-A.3 of current version. >> >> [As WG member] >> >> The original use case may not have been listed in previous document, but it >> was discussed very thoroughly during the adoption call. >> >> It did not convince the WG to adopt the first time, b/c the WG felt existing >> solutions were sufficient -- nothing changed with respect to this for this >> second adoption call that I see. >> >> Thanks, >> Chris. >> >>> >>> There are also the updates for the protocol extension, which absorbs the >>> experts’ various comments from the last update. >>> >>> Until know, it seems people focus mainly on the use cases, we have >>> explained them to them at >>> https://mailarchive.ietf.org/arch/msg/lsr/er9iQ6sgEmvqJSCz_vtZjQ6FB-g/. If >>> there is more question on the responses, please continue the discussion. >>> >>> Regarding to the use case A.1 (Figure 1)which what you mentioned as one >>> failed use case of the first adoption call, what we want to emphasize is >>> that it is not only the configuration challenges in the complex network, >>> but also how to get the correct/error-proof information automatically from >>> the other sides. Such challenges are also mentioned in the existing RFC >>> https://www.rfc-editor.org/rfc/rfc9346.html#section-4.1, >>> https://www.rfc-editor.org/rfc/rfc9346.html#section-5 >>> and also the corresponding parts of RFC5392. >>> >>> Then, If there is solution that can bypass these challenges, why don’t we >>> adopt it? >>> >>> For use case A.1(Figure 2), as Huaimo points out, the existing RFC cannot >>> solve the requirements. >>> >>> For use case A.2, the inter-AS based solution cannot solve the non inter-AS >>> scenario. >>> >>> For use case A.3, it has the same benefits as that for use case A.1(Figure >>> 1) when compared with the existing solution. The
[Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-26.txt
Internet-Draft draft-ietf-lsr-ospfv3-extended-lsa-yang-26.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: YANG Model for OSPFv3 Extended LSAs Authors: Acee Lindem Sharmila Palani Yingzhen Qu Name:draft-ietf-lsr-ospfv3-extended-lsa-yang-26.txt Pages: 29 Dates: 2024-01-15 Abstract: This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-lsr-ospfv3-extended-lsa-yang-26.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-26 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard
Hi Tom, Since this YANG model describes the RFC 8362 encodings, those encodings should be the primary reference all the leaves and identifies. > On Jan 13, 2024, at 07:42, tom petch wrote: > > From: Lsr on behalf of The IESG > > Sent: 11 January 2024 14:35 > > The IESG has received a request from the Link State Routing WG (lsr) to > consider the following document: - 'YANG Model for OSPFv3 Extended LSAs' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-c...@ietf.org mailing lists by 2024-01-25. Exceptionally, comments may > be sent to i...@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > > Most of my comments on this I-D from August are addressed but I still have > some doubts. > > p.11 identity nu-bit > this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a > better reference Agreed. However, I think including both references would be good since RFC 8362 includes the flags in TLVs > > identity la-bit > here RFC8362 changes the meaning so I think the reference to RFC8362 is ok Actually, for the LA-bit, both references would be good. > > p.11 identity p-bit > this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a > better reference Same as nu-bit. > > p.12 identity dn-bit > this is not esplained in the referenced RFC8362; RFC5340 A.4.1.1 would be a > better reference Same as nu-bit. > > p.12 identity e-bit > this is not esplained in the referenced RFC8362; in fact, this one defeats > me. It is present in a daigram, s.3.6, but with no explanation. Reading > RFC5340 it could be A.4.3 but I am not sure If one is familiar with OSPF, it is clear. For AS External and NSSA metrics, there are type 1 and type 2 metrics. Type 1 are simply added to intra-area metric to the originator. Type 2 metrics are considered greater than type 1 metrics. This hasn’t changed since RFC 1247 - just the OSFPv3 and OSPFv3 extended-LSA encodings. Since the description is brief, I’ll include it in its entirety. Thanks, Acee > > Tom Petch > > > > Abstract > > > This document defines a YANG data model augmenting the IETF OSPF YANG > model to provide support for OSPFv3 Link State Advertisement (LSA) > Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide > extensible TLV-based LSAs for the base LSA types defined in RFC 5340. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
[As WG Co-chair] I concur Chris's statement as WG co-chair. The second adoption call should focus on the changes made since the first one, and whether these changes addressed/fixed the issues raised during the first adoption call. Thanks, Yingzhen On Mon, Jan 15, 2024 at 8:15 AM Les Ginsberg (ginsberg) wrote: > I respect that individuals may have different opinions - but it is > important to distinguish what is factual from what is not. > Opinions based upon false information are clearly compromised. > > Please do heed Chris's (as WG chair) admonition to review the first WG > adoption thread. That will reveal to you what the substantive objections > were. > > https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ > https://www.mail-archive.com/search?l=lsr%40ietf.org=stub+link=0=0 > > > Please also do examine the delta between the previous version which was > put up for WG adoption (V3) and the current version (V8) so you can see > what has changed. > > https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03=draft-wang-lsr-stub-link-attributes-08=--html > > Some facts: > > The substantive objections raised during the first adoption call had > nothing to do with use cases - they had to do with: > > a)The use of a prefix to identify a link between two nodes is a flawed > concept. It is not robust enough to be used in cases of unnumbered or > Pt-2-MP. > > b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the > potential use cases and do so more robustly than the Stub-link proposal. > > The latest version of the draft makes no substantive changes to the stub > link concept or its advertisement. > The only substantive change in the latest version is a reorganization of > the presentation of use cases. > But lack of clarity in the use cases was not the basis on which first WG > adoption call was rejected. > > In this thread (the second WG adoption call), the authors have asserted > that they have addressed the concerns raised in the previous adoption call. > They have not. The concept and mechanism to identify a stub link has not > changed. > > In this thread the authors continue to assert that RFC 9346/RFC 5392 > cannot address the use cases. > This is FALSE. > As has been pointed out repeatedly, the existing mechanisms provide a > robust means to uniquely identify inter-AS links using endpoint identifiers > - be they IPv4/IPv6 addresses or Link IDs. > This addresses all cases - numbered and unnumbered. > There is therefore no need for a new mechanism. > > No fact-based argument has been made to justify reconsideration of WG > adoption. > > I hope when people post their opinions, that they consider the facts. > > Les > > > -Original Message- > > From: Lsr On Behalf Of Christian Hopps > > Sent: Wednesday, January 10, 2024 2:17 AM > > To: Huzhibo > > Cc: Acee Lindem ; Yingzhen Qu > > ; lsr@ietf.org > > Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > > (01/05/2024 - 01/19/2024) > > > > [As WG Co-Chair] > > > > Hi Folks, > > > > Before posting support reasons please read and considerl > > *all* the email in the archive covering the first failed > > adoption call. > > > > https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ > > https://www.mail- > > archive.com/search?l=lsr%40ietf.org=stub+link=0=0 > > > > This adoption call should be considering if the changes > > made to the document since it failed to be adopted the > > first time, are sufficient to reverse the WGs previous > > decision. > > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
Hi, As Les suggested in his email, below, I re-reviewed the first WG adoption thread and the delta between the version proposed for the first WG adoption and the version proposed for the second WG adoption, and I completely agree with him that this is a gratuitous and ill-advised change to the IGPs. The only reason advanced for its adoption, in either adoption call, is the groundless assertion that somehow it is a better way of identifying inter-AS links, which seems to be nonsense based upon the past thirty or more years of experience. Thanks, John On Monday, January 15, 2024 at 08:16:59 AM PST, Les Ginsberg (ginsberg) wrote: I respect that individuals may have different opinions - but it is important to distinguish what is factual from what is not. Opinions based upon false information are clearly compromised. Please do heed Chris's (as WG chair) admonition to review the first WG adoption thread. That will reveal to you what the substantive objections were. https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ https://www.mail-archive.com/search?l=lsr%40ietf.org=stub+link=0=0 Please also do examine the delta between the previous version which was put up for WG adoption (V3) and the current version (V8) so you can see what has changed. https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03=draft-wang-lsr-stub-link-attributes-08=--html Some facts: The substantive objections raised during the first adoption call had nothing to do with use cases - they had to do with: a)The use of a prefix to identify a link between two nodes is a flawed concept. It is not robust enough to be used in cases of unnumbered or Pt-2-MP. b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the potential use cases and do so more robustly than the Stub-link proposal. The latest version of the draft makes no substantive changes to the stub link concept or its advertisement. The only substantive change in the latest version is a reorganization of the presentation of use cases. But lack of clarity in the use cases was not the basis on which first WG adoption call was rejected. In this thread (the second WG adoption call), the authors have asserted that they have addressed the concerns raised in the previous adoption call. They have not. The concept and mechanism to identify a stub link has not changed. In this thread the authors continue to assert that RFC 9346/RFC 5392 cannot address the use cases. This is FALSE. As has been pointed out repeatedly, the existing mechanisms provide a robust means to uniquely identify inter-AS links using endpoint identifiers - be they IPv4/IPv6 addresses or Link IDs. This addresses all cases - numbered and unnumbered. There is therefore no need for a new mechanism. No fact-based argument has been made to justify reconsideration of WG adoption. I hope when people post their opinions, that they consider the facts. Les > -Original Message- > From: Lsr On Behalf Of Christian Hopps > Sent: Wednesday, January 10, 2024 2:17 AM > To: Huzhibo > Cc: Acee Lindem ; Yingzhen Qu > ; lsr@ietf.org > Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > (01/05/2024 - 01/19/2024) > > [As WG Co-Chair] > > Hi Folks, > > Before posting support reasons please read and considerl > *all* the email in the archive covering the first failed > adoption call. > > https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ > https://www.mail- > archive.com/search?l=lsr%40ietf.org=stub+link=0=0 > > This adoption call should be considering if the changes > made to the document since it failed to be adopted the > first time, are sufficient to reverse the WGs previous > decision. > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [Editorial Errata Reported] RFC4576 (7765)
All, The Errata is correct and should be accepted. Thanks, Acee > On Jan 15, 2024, at 13:12, RFC Errata System > wrote: > > The following errata report has been submitted for RFC4576, > "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in > BGP/MPLS IP Virtual Private Networks (VPNs)". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7765 > > -- > Type: Editorial > Reported by: Julian Cowley > > Section: 7 > > Original Text > - > [OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, > April 1972. > > Corrected Text > -- > [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. > > Notes > - > The error was caused by a missing 2 in front of the RFC number in the > reference. > > Instructions: > - > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -- > RFC4576 (draft-ietf-ospf-2547-dnbit-04) > -- > Title : Using a Link State Advertisement (LSA) Options Bit to > Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) > Publication Date: June 2006 > Author(s) : E. Rosen, P. Psenak, P. Pillay-Esnault > Category: PROPOSED STANDARD > Source : Open Shortest Path First IGP > Area: Routing > Stream : IETF > Verifying Party : IESG > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [Editorial Errata Reported] RFC4576 (7765)
The following errata report has been submitted for RFC4576, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7765 -- Type: Editorial Reported by: Julian Cowley Section: 7 Original Text - [OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, April 1972. Corrected Text -- [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. Notes - The error was caused by a missing 2 in front of the RFC number in the reference. Instructions: - This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -- RFC4576 (draft-ietf-ospf-2547-dnbit-04) -- Title : Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) Publication Date: June 2006 Author(s) : E. Rosen, P. Psenak, P. Pillay-Esnault Category: PROPOSED STANDARD Source : Open Shortest Path First IGP Area: Routing Stream : IETF Verifying Party : IESG ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-extended-flags-00.txt
From: Lsr on behalf of internet-dra...@ietf.org Sent: 10 December 2023 03:37 Internet-Draft draft-ietf-lsr-ospf-prefix-extended-flags-00.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: Prefix Flag Extension for OSPFv2 and OSPFv3 Authors: Ran Chen Detao Zhao Peter Psenak Ketan Talaulikar Name:draft-ietf-lsr-ospf-prefix-extended-flags-00.txt Pages: 10 Dates: 2023-12-09 Abstract: Within OSPF, each prefix is advertised along with an 8-bit field of capabilities, by using the Prefix Options (OSPFv3) and the flag flield in the OSPFv2 Extended Prefix TLV (OSPFv2). However, for OSPFv3, all the bits of the Prefix Options have already been assigned, and for OSPFv2, there are not many undefined bits left in the OSPFv2 Extended Prefix TLV. This document solves the problem of insufficient existing flags, and defines the variable length Prefix attributes Sub-TLVs for OSPFv2 and OSPFv3 respectively for the extended flag fields. Section 2 talks of Types TBD1 and TBD2 IANA Considerations asks IANA to assign TBD and TBD. I think that these need bringing in line Tom Petch ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
I respect that individuals may have different opinions - but it is important to distinguish what is factual from what is not. Opinions based upon false information are clearly compromised. Please do heed Chris's (as WG chair) admonition to review the first WG adoption thread. That will reveal to you what the substantive objections were. https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ https://www.mail-archive.com/search?l=lsr%40ietf.org=stub+link=0=0 Please also do examine the delta between the previous version which was put up for WG adoption (V3) and the current version (V8) so you can see what has changed. https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03=draft-wang-lsr-stub-link-attributes-08=--html Some facts: The substantive objections raised during the first adoption call had nothing to do with use cases - they had to do with: a)The use of a prefix to identify a link between two nodes is a flawed concept. It is not robust enough to be used in cases of unnumbered or Pt-2-MP. b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the potential use cases and do so more robustly than the Stub-link proposal. The latest version of the draft makes no substantive changes to the stub link concept or its advertisement. The only substantive change in the latest version is a reorganization of the presentation of use cases. But lack of clarity in the use cases was not the basis on which first WG adoption call was rejected. In this thread (the second WG adoption call), the authors have asserted that they have addressed the concerns raised in the previous adoption call. They have not. The concept and mechanism to identify a stub link has not changed. In this thread the authors continue to assert that RFC 9346/RFC 5392 cannot address the use cases. This is FALSE. As has been pointed out repeatedly, the existing mechanisms provide a robust means to uniquely identify inter-AS links using endpoint identifiers - be they IPv4/IPv6 addresses or Link IDs. This addresses all cases - numbered and unnumbered. There is therefore no need for a new mechanism. No fact-based argument has been made to justify reconsideration of WG adoption. I hope when people post their opinions, that they consider the facts. Les > -Original Message- > From: Lsr On Behalf Of Christian Hopps > Sent: Wednesday, January 10, 2024 2:17 AM > To: Huzhibo > Cc: Acee Lindem ; Yingzhen Qu > ; lsr@ietf.org > Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > (01/05/2024 - 01/19/2024) > > [As WG Co-Chair] > > Hi Folks, > > Before posting support reasons please read and considerl > *all* the email in the archive covering the first failed > adoption call. > > https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ > https://www.mail- > archive.com/search?l=lsr%40ietf.org=stub+link=0=0 > > This adoption call should be considering if the changes > made to the document since it failed to be adopted the > first time, are sufficient to reverse the WGs previous > decision. > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024)
Hi, Chris: The first adoption call focus on the A.1 use case(figure 1), not cover all of the use case that listed in A.1-A.3 For A.1(Figure 1) use case, previous discussions focus on mainly the benefits of the configuration simplification, which you emphasize that IGP does not mainly for such work. OK, now let us consider other issues of the existing solutions——how to get the related information automatically and error-proofing? RFC9346 and RFC 5392 mentioned all such challenges, they even propose to use BGP to cross verify such information, which is still on the imagination stage. Then, if there is solution can bypass such requirements, should we consider it then? Especially from the deployment viewpoint of the operator? Together with the above points, the proposed solution can cover other use cases, which are not discussed throughly in previous adoption call. If one proposal can simply the deployment requirements of existing solution for some cases(A.1 Figure 1 and A.3), can solve some case that existing solution can’t(A.1 Figure 2 and A.2) should we accept it then? We can discuss throughly on the above statements then for the second adoption call, pass the configuration simplification arguments. Aijun Wang China Telecom > On Jan 15, 2024, at 20:19, Christian Hopps wrote: > > > >> On Jan 15, 2024, at 06:27, Aijun Wang wrote: >> >> Hi, Chris： >> >> There are significant changes from the last adoption call(version 02) to the >> current version(version 08). Then I doubt the valid information from the >> previous discussions. >> >> For example, there is no concrete use cases description in the previous >> version, which is provided in the appendix A.1-A.3 of current version. > > [As WG member] > > The original use case may not have been listed in previous document, but it > was discussed very thoroughly during the adoption call. > > It did not convince the WG to adopt the first time, b/c the WG felt existing > solutions were sufficient -- nothing changed with respect to this for this > second adoption call that I see. > > Thanks, > Chris. > >> >> There are also the updates for the protocol extension, which absorbs the >> experts’ various comments from the last update. >> >> Until know, it seems people focus mainly on the use cases, we have explained >> them to them at >> https://mailarchive.ietf.org/arch/msg/lsr/er9iQ6sgEmvqJSCz_vtZjQ6FB-g/. If >> there is more question on the responses, please continue the discussion. >> >> Regarding to the use case A.1 (Figure 1)which what you mentioned as one >> failed use case of the first adoption call, what we want to emphasize is >> that it is not only the configuration challenges in the complex network, but >> also how to get the correct/error-proof information automatically from the >> other sides. Such challenges are also mentioned in the existing RFC >> https://www.rfc-editor.org/rfc/rfc9346.html#section-4.1, >> https://www.rfc-editor.org/rfc/rfc9346.html#section-5 >> and also the corresponding parts of RFC5392. >> >> Then, If there is solution that can bypass these challenges, why don’t we >> adopt it? >> >> For use case A.1(Figure 2), as Huaimo points out, the existing RFC cannot >> solve the requirements. >> >> For use case A.2, the inter-AS based solution cannot solve the non inter-AS >> scenario. >> >> For use case A.3, it has the same benefits as that for use case A.1(Figure >> 1) when compared with the existing solution. The differences are that >> A.1(Figure) focuses on the topology recovery, A.3 focuses on forward path >> optimization. >> >> When we consider whether one proposal is reasonable enough, we should not >> only consider the implementation possibilities, but also the deployment >> challenges(not configuration/management). If it is not practical for the >> deployment, then what’s the value of standard/implementation? >> >> And, people are arguing that there exists inter-AS TE >> solutions(RFC9346/RFC5392), but how many operators have deployed them in the >> network? Are anyone considering the reason that hinders their deployments? >> >> Aijun Wang >> China Telecom >> >>> On Jan 15, 2024, at 17:35, Christian Hopps wrote: >>> >>> >>> Liyan Gong writes: >>> Hi WG, I Support its adoption. Currently there is no automatic and error-proof way to get the related information of the other ends for inter-as links, it is difficult for operator to rebuild the complex inter-as topology. The proposed protocol extension in this draft can assist the operator to overcome the above obstacles. >>> >>> [As WG member] >>> >>> This use-case is covered by other solutions, and was discussed and denied >>> as a reason to adopt already in the first failed adoption call. >>> >>> [As co-char] >>> >>> This second call for adoption indicated that people should go and read the >>> first failed adoption call and the ton of email it
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024)
> On Jan 15, 2024, at 06:27, Aijun Wang wrote: > > Hi, Chris： > > There are significant changes from the last adoption call(version 02) to the > current version(version 08). Then I doubt the valid information from the > previous discussions. > > For example, there is no concrete use cases description in the previous > version, which is provided in the appendix A.1-A.3 of current version. [As WG member] The original use case may not have been listed in previous document, but it was discussed very thoroughly during the adoption call. It did not convince the WG to adopt the first time, b/c the WG felt existing solutions were sufficient -- nothing changed with respect to this for this second adoption call that I see. Thanks, Chris. > > There are also the updates for the protocol extension, which absorbs the > experts’ various comments from the last update. > > Until know, it seems people focus mainly on the use cases, we have explained > them to them at > https://mailarchive.ietf.org/arch/msg/lsr/er9iQ6sgEmvqJSCz_vtZjQ6FB-g/. If > there is more question on the responses, please continue the discussion. > > Regarding to the use case A.1 (Figure 1)which what you mentioned as one > failed use case of the first adoption call, what we want to emphasize is that > it is not only the configuration challenges in the complex network, but also > how to get the correct/error-proof information automatically from the other > sides. Such challenges are also mentioned in the existing RFC > https://www.rfc-editor.org/rfc/rfc9346.html#section-4.1, > https://www.rfc-editor.org/rfc/rfc9346.html#section-5 > and also the corresponding parts of RFC5392. > > Then, If there is solution that can bypass these challenges, why don’t we > adopt it? > > For use case A.1(Figure 2), as Huaimo points out, the existing RFC cannot > solve the requirements. > > For use case A.2, the inter-AS based solution cannot solve the non inter-AS > scenario. > > For use case A.3, it has the same benefits as that for use case A.1(Figure 1) > when compared with the existing solution. The differences are that > A.1(Figure) focuses on the topology recovery, A.3 focuses on forward path > optimization. > > When we consider whether one proposal is reasonable enough, we should not > only consider the implementation possibilities, but also the deployment > challenges(not configuration/management). If it is not practical for the > deployment, then what’s the value of standard/implementation? > > And, people are arguing that there exists inter-AS TE > solutions(RFC9346/RFC5392), but how many operators have deployed them in the > network? Are anyone considering the reason that hinders their deployments? > > Aijun Wang > China Telecom > >> On Jan 15, 2024, at 17:35, Christian Hopps wrote: >> >> >> Liyan Gong writes: >> >>> Hi WG, >>> >>> >>> I Support its adoption. >>> >>> Currently there is no automatic and error-proof way to get the >>> related information of the other ends for inter-as links, it is >>> difficult for operator to rebuild the complex inter-as topology. >>> >>> The proposed protocol extension in this draft can assist the operator >>> to overcome the above obstacles. >> >> [As WG member] >> >> This use-case is covered by other solutions, and was discussed and denied as >> a reason to adopt already in the first failed adoption call. >> >> [As co-char] >> >> This second call for adoption indicated that people should go and read the >> first failed adoption call and the ton of email it generated. Repeating the >> same points found technically lacking the first time is unproductive and >> will not positively influence rough consensus a second time just b/c they >> are being repeated over and over. >> >> Thanks, >> Chris. >> >> >>> >>> >>> Best Regards, >>> >>> Liyan >>> >>> >>>邮件原文 >>>发件人：Yingzhen Qu >>>收件人：lsr ,lsr-chairs >>>抄 送: (无) >>>发送时间：2024-01-06 08:23:00 >>>主题：[Lsr] >>> WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/ >>>2024 - 01/19/2024) >>> >>>Hi, >>> >>>This begins a 2 week WG Adoption Call for the following >>> draft:https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/Please >>> indicate your support or objections by January 19th, 2024. >>> >>>Authors, please respond to the list indicating whether you are aware of >>> any IPR that applies to the draft. >>> >>>*** Please note that this is the second WG adoption poll of the >>>draft. The first one was tried two years ago and you can see the >>>discussions in the archive: >>>[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 >>>(ietf.org) >>> >>> >>>Thanks, >>> >>>Yingzhen >>> >>> >> >> ___ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024)
Hi, Chris： There are significant changes from the last adoption call(version 02) to the current version(version 08). Then I doubt the valid information from the previous discussions. For example, there is no concrete use cases description in the previous version, which is provided in the appendix A.1-A.3 of current version. There are also the updates for the protocol extension, which absorbs the experts’ various comments from the last update. Until know, it seems people focus mainly on the use cases, we have explained them to them at https://mailarchive.ietf.org/arch/msg/lsr/er9iQ6sgEmvqJSCz_vtZjQ6FB-g/. If there is more question on the responses, please continue the discussion. Regarding to the use case A.1 (Figure 1)which what you mentioned as one failed use case of the first adoption call, what we want to emphasize is that it is not only the configuration challenges in the complex network, but also how to get the correct/error-proof information automatically from the other sides. Such challenges are also mentioned in the existing RFC https://www.rfc-editor.org/rfc/rfc9346.html#section-4.1, https://www.rfc-editor.org/rfc/rfc9346.html#section-5 and also the corresponding parts of RFC5392. Then, If there is solution that can bypass these challenges, why don’t we adopt it? For use case A.1(Figure 2), as Huaimo points out, the existing RFC cannot solve the requirements. For use case A.2, the inter-AS based solution cannot solve the non inter-AS scenario. For use case A.3, it has the same benefits as that for use case A.1(Figure 1) when compared with the existing solution. The differences are that A.1(Figure) focuses on the topology recovery, A.3 focuses on forward path optimization. When we consider whether one proposal is reasonable enough, we should not only consider the implementation possibilities, but also the deployment challenges(not configuration/management). If it is not practical for the deployment, then what’s the value of standard/implementation? And, people are arguing that there exists inter-AS TE solutions(RFC9346/RFC5392), but how many operators have deployed them in the network? Are anyone considering the reason that hinders their deployments? Aijun Wang China Telecom > On Jan 15, 2024, at 17:35, Christian Hopps wrote: > > Liyan Gong writes: > >> Hi WG, >> >> >> I Support its adoption. >> >> Currently there is no automatic and error-proof way to get the >> related information of the other ends for inter-as links, it is >> difficult for operator to rebuild the complex inter-as topology. >> >> The proposed protocol extension in this draft can assist the operator >> to overcome the above obstacles. > > [As WG member] > > This use-case is covered by other solutions, and was discussed and denied as > a reason to adopt already in the first failed adoption call. > > [As co-char] > > This second call for adoption indicated that people should go and read the > first failed adoption call and the ton of email it generated. Repeating the > same points found technically lacking the first time is unproductive and will > not positively influence rough consensus a second time just b/c they are > being repeated over and over. > > Thanks, > Chris. > > >> >> >> Best Regards, >> >> Liyan >> >> >>邮件原文 >>发件人：Yingzhen Qu >>收件人：lsr ,lsr-chairs >>抄 送: (无) >>发送时间：2024-01-06 08:23:00 >>主题：[Lsr] >> WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/ >>2024 - 01/19/2024) >> >>Hi, >> >>This begins a 2 week WG Adoption Call for the following >> draft:https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/Please >> indicate your support or objections by January 19th, 2024. >> >>Authors, please respond to the list indicating whether you are aware of >> any IPR that applies to the draft. >> >>*** Please note that this is the second WG adoption poll of the >>draft. The first one was tried two years ago and you can see the >>discussions in the archive: >>[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 >>(ietf.org) >> >> >>Thanks, >> >>Yingzhen > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024)
Liyan Gong writes: Hi WG, I Support its adoption. Currently there is no automatic and error-proof way to get the related information of the other ends for inter-as links, it is difficult for operator to rebuild the complex inter-as topology. The proposed protocol extension in this draft can assist the operator to overcome the above obstacles. [As WG member] This use-case is covered by other solutions, and was discussed and denied as a reason to adopt already in the first failed adoption call. [As co-char] This second call for adoption indicated that people should go and read the first failed adoption call and the ton of email it generated. Repeating the same points found technically lacking the first time is unproductive and will not positively influence rough consensus a second time just b/c they are being repeated over and over. Thanks, Chris. Best Regards, Liyan 邮件原文 发件人：Yingzhen Qu 收件人：lsr ,lsr-chairs 抄 送: (无) 发送时间：2024-01-06 08:23:00 主题：[Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/ 2024 - 01/19/2024) Hi, This begins a 2 week WG Adoption Call for the following draft:https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/Please indicate your support or objections by January 19th, 2024. Authors, please respond to the list indicating whether you are aware of any IPR that applies to the draft. *** Please note that this is the second WG adoption poll of the draft. The first one was tried two years ago and you can see the discussions in the archive: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org) Thanks, Yingzhen signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
"duzongp...@foxmail.com" writes: Hi, all I support the adoption. I agree with the idea: Considering there are many links and complex interconnections among the ASBRs that located in different AS domains, the proposed protocol extension can certainly ease the recovery and management of inter-AS topologies. [As WG member] Key word "Management", The WG has a long-standing agreement that the IGPs are not to be used as a replacement for a proper NMS system. This was also covered in the previous failed WG adoption call. Exposing a possible inter-domain link is a use case covered by existing solutions and was considered a non-supporting use case in the previous failed adoption call. [As co-chair] The following comment regards more than just this mail since I've been seeing it in other supporting emails as well -- repeating points that were found technically lacking from the first failed WG adoption call are not going to positively influence rough consensus for adoption in this repeated adoption call, no matter how many people chime in to repeat them. Thanks, Chris. Best Regards Zongpeng Du duzongp...@foxmail.com & duzongp...@chinamobile.com From: Yingzhen Qu Date: 2024-01-06 08:23 To: lsr; lsr-chairs Subject: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) Hi, This begins a 2 week WG Adoption Call for the following draft: https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/ Please indicate your support or objections by January 19th, 2024. Authors, please respond to the list indicating whether you are aware of any IPR that applies to the draft. *** Please note that this is the second WG adoption poll of the draft. The first one was tried two years ago and you can see the discussions in the archive: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org) Thanks, Yingzhen signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024)
Hi WG, I Support its adoption. Currently there is no automatic and error-proof way to get the related information of the other ends for inter-as links, it is difficult for operator to rebuild the complex inter-as topology. The proposed protocol extension in this draft can assist the operator to overcome the above obstacles. Best Regards, Liyan 邮件原文发件人：Yingzhen Qu 收件人：lsr ,lsr-chairs 抄 送: (无)发送时间：2024-01-06 08:23:00主题：[Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024)Hi,This begins a 2 week WG Adoption Call for the following draft:https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/Please indicate your support or objections by January 19th, 2024. Authors, please respond to the list indicating whether you are aware of any IPR that applies to the draft. *** Please note that this is the second WG adoption poll of the draft. The first one was tried two years ago and you can see the discussions in the archive: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org) Thanks,Yingzhen ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
Hi, all I support the adoption. I agree with the idea: Considering there are many links and complex interconnections among the ASBRs that located in different AS domains, the proposed protocol extension can certainly ease the recovery and management of inter-AS topologies. Best Regards Zongpeng Du duzongp...@foxmail.com & duzongp...@chinamobile.com From: Yingzhen Qu Date: 2024-01-06 08:23 To: lsr; lsr-chairs Subject: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) Hi, This begins a 2 week WG Adoption Call for the following draft: https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/ Please indicate your support or objections by January 19th, 2024. Authors, please respond to the list indicating whether you are aware of any IPR that applies to the draft. *** Please note that this is the second WG adoption poll of the draft. The first one was tried two years ago and you can see the discussions in the archive: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org) Thanks,Yingzhen ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
