Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
On 29/07/2022 08:35, Aijun Wang wrote: Hi, Peter: I think you and all the subscribers of the LSR mail list have noticed not only Zhibo express the opinions that LSInfinity cannot be used to indicate the prefix is unreachable. There should exist other explicit indication. Should we stop arguing this point then? I have not seen any technical evidence why LSInfinity is not sufficient. Repeating same invalid arguments over and over will not make them valid. Peter Aijun Wang China Telecom On Jul 29, 2022, at 19:19, Peter Psenak wrote: Zhibo, On 28/07/2022 22:07, Huzhibo wrote: Peter -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Friday, July 29, 2022 8:33 AM To: Aijun Wang ; Acee Lindem (acee) Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg) ; draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr Subject: Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement Aijun, On 28/07/2022 19:55, Aijun Wang wrote: Hi, Acee: Thanks for your comments, but most of them are indefensible, especially the conclusion. As you have also noticed, UPA mechanism doesn’t consider the network partition scenarios, doesn’t consider how to control the number of advertisement of unreachable messages, doesn’t provide the explicit notification of unreachable statement(as also pointed out Ketan, Bruno etc.), then how you hurry to get the conclusion that UPA is superior to PUA? IETF documents are not deployment guides, nor design or implementation documents, not the source of education for the other vendors. IETF documents are there to specify the bare minimum to achieve interoperability. In other words, the fact that you put more content in your document, does not make it any better. Contrary, the less you need to do to achieve the interoperability, the better it is. [HZB] More content you mentioned of the documents are addresses comments on the promotion of this document. It is an essential part of a complete solution. RFC 5305 define that LSInfinity metric is used for other purposes other than building the normal routing table. UPA uses LSInfinity metric only to identify unreachable prefixes, which is contrary to RFC 5305. no, it is in perfect compliance with RFC 5305. [draft-ietf-lsr-ip-flexalgo] also uses LSInfinity metric. It may also be applied to other purposes. which is orthogonal to our discussion here, because if the valid metric exists in IP Algorithm Prefix Reachability Sub-TLV, the metric in parent TLV is ignored. There is no problem here. Therefore, using LSInfinity metric alone is not enough. that's what you claim, bit that is not necessary true. Peter In conclusion, the PUA solution is more complete and the unreachable prefix is defined in a more reasonable manner. Zhibo Hu Peter We have yet mentioned that PUA mechanism has been discussed two years before the UPA solution. More responses are inline. Anyway, I am glad that your comments have some bases, although you misunderstood something. Aijun Wang China Telecom On Jul 29, 2022, at 02:04, Acee Lindem (acee) wrote: Speaking as WG Member: Hi Ketan, Thanks for pointing out the similarities. Even after the recent changes, there are still some difference between the drafts which I’ll describe in the baseless comments which follow. For conciseness, I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak). 1. Backward Compatibility – Now that PUA has appropriated the metric mechanisms from UPA, it is also backward compatible. However, PUA still proposes extensions the IGPs to advertise the PUA capabilities and says the nodes may misbehave if they don’t agree on these capabilities. I guess removing these was omitted when the UPA metric mechanisms were appropriated. WAJ] No. the context in the document just describes why and when the LSInfinity is necessary. The usages of LSInfinity in two drafts are different: one(PUA) is to avoid the misbehavior(which is conform to the RFC rules), another(UPA) is to indicate the unreachable information(which is not described in the RFC rules) 1. 2. Receive Router Behavior – For UPA, the unreachable prefix notification is solely for an event signal to be used by other routers in the IGP domain to trigger actions, e.g., BGP PIC excluding the unreachable prefix. PUA is used for the switchover of services as well but is also used to modify persistent state. In section 4, the PUA advertisement will trigger the advertisement of the prefix by an ABR that does have a route to the unreachable prefix advertised by another ABR. [WAJ] Is this one evidence that PUA covers UPA? 2. 3. Advertisement Persistence – PUA is advertised like any other LSA and presumably advertised as long as the prefix is unreachable. Conversely, UPA is an ephemeral LSA that will be withdrawn after enough time is allowed for the event notification
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Hi, Peter: I think you and all the subscribers of the LSR mail list have noticed not only Zhibo express the opinions that LSInfinity cannot be used to indicate the prefix is unreachable. There should exist other explicit indication. Should we stop arguing this point then? Aijun Wang China Telecom > On Jul 29, 2022, at 19:19, Peter Psenak wrote: > > Zhibo, > >> On 28/07/2022 22:07, Huzhibo wrote: >> Peter >>> -Original Message- >>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak >>> Sent: Friday, July 29, 2022 8:33 AM >>> To: Aijun Wang ; Acee Lindem (acee) >>> >>> Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg) >>> ; >>> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr >>> Subject: Re: [Lsr] Comments on >>> draft-wang-lsr-prefix-unreachable-annoucement >>> >>> Aijun, >>> >>> On 28/07/2022 19:55, Aijun Wang wrote: >>>> Hi, Acee: >>>> >>>> Thanks for your comments, but most of them are indefensible, >>>> especially the conclusion. >>>> As you have also noticed, UPA mechanism doesn’t consider the network >>>> partition scenarios, doesn’t consider how to control the number of >>>> advertisement of unreachable messages, doesn’t provide the explicit >>>> notification of unreachable statement(as also pointed out Ketan, Bruno >>>> etc.), then how you hurry to get the conclusion that UPA is superior to >>>> PUA? >>> >>> IETF documents are not deployment guides, nor design or implementation >>> documents, not the source of education for the other vendors. >>> >>> IETF documents are there to specify the bare minimum to achieve >>> interoperability. >>> >>> In other words, the fact that you put more content in your document, does >>> not >>> make it any better. Contrary, the less you need to do to achieve the >>> interoperability, the better it is. >> [HZB] More content you mentioned of the documents are addresses comments on >> the promotion of this document. >> It is an essential part of a complete solution. >> RFC 5305 define that LSInfinity metric is used for other purposes other than >> building the normal routing table. UPA uses LSInfinity metric only to >> identify unreachable prefixes, which is contrary to RFC 5305. > > no, it is in perfect compliance with RFC 5305. > >> [draft-ietf-lsr-ip-flexalgo] also uses LSInfinity metric. It may also be >> applied to other purposes. > > which is orthogonal to our discussion here, because if the valid metric > exists in IP Algorithm Prefix Reachability Sub-TLV, the metric in parent TLV > is ignored. There is no problem here. > >> Therefore, using LSInfinity metric alone is not enough. > > that's what you claim, bit that is not necessary true. > > Peter > > >> In conclusion, the PUA solution is more complete and the unreachable prefix >> is defined in a more reasonable manner. >> Zhibo Hu >>> Peter >>> >>> >>>> >>>> We have yet mentioned that PUA mechanism has been discussed two years >>>> before the UPA solution. >>>> >>>> More responses are inline. Anyway, I am glad that your comments have >>>> some bases, although you misunderstood something. >>>> >>>> Aijun Wang >>>> China Telecom >>>> >>>>> On Jul 29, 2022, at 02:04, Acee Lindem (acee) wrote: >>>>> >>>>> Speaking as WG Member: >>>>> >>>>> Hi Ketan, >>>>> >>>>> Thanks for pointing out the similarities. Even after the recent >>>>> changes, there are still some difference between the drafts which >>>>> I’ll describe in the baseless comments which follow. For conciseness, >>>>> I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak). >>>>> >>>>> 1. Backward Compatibility – Now that PUA has appropriated the metric >>>>> mechanisms from UPA, it is also backward compatible. However, PUA >>>>> still proposes extensions the IGPs to advertise the PUA >>>>> capabilities and says the nodes may misbehave if they don’t agree >>>>> on these capabilities. I guess removing these was omitted when the >>>>> UPA metric mechanisms were appropriated. >>>> >>>> WAJ] No. the context in the document just describes why and when the &
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Zhibo, On 28/07/2022 22:07, Huzhibo wrote: Peter -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Friday, July 29, 2022 8:33 AM To: Aijun Wang ; Acee Lindem (acee) Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg) ; draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr Subject: Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement Aijun, On 28/07/2022 19:55, Aijun Wang wrote: Hi, Acee: Thanks for your comments, but most of them are indefensible, especially the conclusion. As you have also noticed, UPA mechanism doesn’t consider the network partition scenarios, doesn’t consider how to control the number of advertisement of unreachable messages, doesn’t provide the explicit notification of unreachable statement(as also pointed out Ketan, Bruno etc.), then how you hurry to get the conclusion that UPA is superior to PUA? IETF documents are not deployment guides, nor design or implementation documents, not the source of education for the other vendors. IETF documents are there to specify the bare minimum to achieve interoperability. In other words, the fact that you put more content in your document, does not make it any better. Contrary, the less you need to do to achieve the interoperability, the better it is. [HZB] More content you mentioned of the documents are addresses comments on the promotion of this document. It is an essential part of a complete solution. RFC 5305 define that LSInfinity metric is used for other purposes other than building the normal routing table. UPA uses LSInfinity metric only to identify unreachable prefixes, which is contrary to RFC 5305. no, it is in perfect compliance with RFC 5305. [draft-ietf-lsr-ip-flexalgo] also uses LSInfinity metric. It may also be applied to other purposes. which is orthogonal to our discussion here, because if the valid metric exists in IP Algorithm Prefix Reachability Sub-TLV, the metric in parent TLV is ignored. There is no problem here. Therefore, using LSInfinity metric alone is not enough. that's what you claim, bit that is not necessary true. Peter In conclusion, the PUA solution is more complete and the unreachable prefix is defined in a more reasonable manner. Zhibo Hu Peter We have yet mentioned that PUA mechanism has been discussed two years before the UPA solution. More responses are inline. Anyway, I am glad that your comments have some bases, although you misunderstood something. Aijun Wang China Telecom On Jul 29, 2022, at 02:04, Acee Lindem (acee) wrote: Speaking as WG Member: Hi Ketan, Thanks for pointing out the similarities. Even after the recent changes, there are still some difference between the drafts which I’ll describe in the baseless comments which follow. For conciseness, I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak). 1. Backward Compatibility – Now that PUA has appropriated the metric mechanisms from UPA, it is also backward compatible. However, PUA still proposes extensions the IGPs to advertise the PUA capabilities and says the nodes may misbehave if they don’t agree on these capabilities. I guess removing these was omitted when the UPA metric mechanisms were appropriated. WAJ] No. the context in the document just describes why and when the LSInfinity is necessary. The usages of LSInfinity in two drafts are different: one(PUA) is to avoid the misbehavior(which is conform to the RFC rules), another(UPA) is to indicate the unreachable information(which is not described in the RFC rules) 1. 2. Receive Router Behavior – For UPA, the unreachable prefix notification is solely for an event signal to be used by other routers in the IGP domain to trigger actions, e.g., BGP PIC excluding the unreachable prefix. PUA is used for the switchover of services as well but is also used to modify persistent state. In section 4, the PUA advertisement will trigger the advertisement of the prefix by an ABR that does have a route to the unreachable prefix advertised by another ABR. [WAJ] Is this one evidence that PUA covers UPA? 2. 3. Advertisement Persistence – PUA is advertised like any other LSA and presumably advertised as long as the prefix is unreachable. Conversely, UPA is an ephemeral LSA that will be withdrawn after enough time is allowed for the event notification to propagate. [WAJ] No. if there is no network update again, the PUA will not be advertised “as long as the prefix is unreachable “. Actually, there is description in the document: “The advertisement of PUAM message should only last one configurable period to allow the services that run on the failure prefixes are switchovered. If one prefix is missed before the PUAM takes effect, the ABR will not declare its absence via the PUAM.” I think you may ignore them. 3. In my opinion, UPA is superior to PUA since
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Peter > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak > Sent: Friday, July 29, 2022 8:33 AM > To: Aijun Wang ; Acee Lindem (acee) > > Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg) > ; > draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr > Subject: Re: [Lsr] Comments on > draft-wang-lsr-prefix-unreachable-annoucement > > Aijun, > > On 28/07/2022 19:55, Aijun Wang wrote: > > Hi, Acee: > > > > Thanks for your comments, but most of them are indefensible, > > especially the conclusion. > > As you have also noticed, UPA mechanism doesn’t consider the network > > partition scenarios, doesn’t consider how to control the number of > > advertisement of unreachable messages, doesn’t provide the explicit > > notification of unreachable statement(as also pointed out Ketan, Bruno > > etc.), then how you hurry to get the conclusion that UPA is superior to PUA? > > IETF documents are not deployment guides, nor design or implementation > documents, not the source of education for the other vendors. > > IETF documents are there to specify the bare minimum to achieve > interoperability. > > In other words, the fact that you put more content in your document, does not > make it any better. Contrary, the less you need to do to achieve the > interoperability, the better it is. [HZB] More content you mentioned of the documents are addresses comments on the promotion of this document. It is an essential part of a complete solution. RFC 5305 define that LSInfinity metric is used for other purposes other than building the normal routing table. UPA uses LSInfinity metric only to identify unreachable prefixes, which is contrary to RFC 5305. [draft-ietf-lsr-ip-flexalgo] also uses LSInfinity metric. It may also be applied to other purposes. Therefore, using LSInfinity metric alone is not enough. In conclusion, the PUA solution is more complete and the unreachable prefix is defined in a more reasonable manner. Zhibo Hu > Peter > > > > > > We have yet mentioned that PUA mechanism has been discussed two years > > before the UPA solution. > > > > More responses are inline. Anyway, I am glad that your comments have > > some bases, although you misunderstood something. > > > > Aijun Wang > > China Telecom > > > >> On Jul 29, 2022, at 02:04, Acee Lindem (acee) wrote: > >> > >> Speaking as WG Member: > >> > >> Hi Ketan, > >> > >> Thanks for pointing out the similarities. Even after the recent > >> changes, there are still some difference between the drafts which > >> I’ll describe in the baseless comments which follow. For conciseness, > >> I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak). > >> > >> 1. Backward Compatibility – Now that PUA has appropriated the metric > >> mechanisms from UPA, it is also backward compatible. However, PUA > >> still proposes extensions the IGPs to advertise the PUA > >> capabilities and says the nodes may misbehave if they don’t agree > >> on these capabilities. I guess removing these was omitted when the > >> UPA metric mechanisms were appropriated. > > > > WAJ] No. the context in the document just describes why and when the > > LSInfinity is necessary. The usages of LSInfinity in two drafts are > > different: one(PUA) is to avoid the misbehavior(which is conform to > > the RFC rules), another(UPA) is to indicate the unreachable > > information(which is not described in the RFC rules) > > > >> 1. > >> 2. Receive Router Behavior – For UPA, the unreachable prefix > >> notification is solely for an event signal to be used by other > >> routers in the IGP domain to trigger actions, e.g., BGP PIC > >> excluding the unreachable prefix. PUA is used for the switchover > >> of services as well but is also used to modify persistent state. > >> In section 4, the PUA advertisement will trigger the advertisement > >> of the prefix by an ABR that does have a route to the unreachable > >> prefix advertised by another ABR. > > [WAJ] Is this one evidence that PUA covers UPA? > >> > >> 2. > >> 3. Advertisement Persistence – PUA is advertised like any other LSA > >> and presumably advertised as long as the prefix is unreachable. > >> Conversely, UPA is an ephemeral LSA that will be withdrawn after > >> enough time is allowed for the event notification to propagate. > > [WAJ] No. if there is no network update again, the PUA will not be >
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Aijun, On 28/07/2022 19:55, Aijun Wang wrote: Hi, Acee: Thanks for your comments, but most of them are indefensible, especially the conclusion. As you have also noticed, UPA mechanism doesn’t consider the network partition scenarios, doesn’t consider how to control the number of advertisement of unreachable messages, doesn’t provide the explicit notification of unreachable statement(as also pointed out Ketan, Bruno etc.), then how you hurry to get the conclusion that UPA is superior to PUA? IETF documents are not deployment guides, nor design or implementation documents, not the source of education for the other vendors. IETF documents are there to specify the bare minimum to achieve interoperability. In other words, the fact that you put more content in your document, does not make it any better. Contrary, the less you need to do to achieve the interoperability, the better it is. Peter We have yet mentioned that PUA mechanism has been discussed two years before the UPA solution. More responses are inline. Anyway, I am glad that your comments have some bases, although you misunderstood something. Aijun Wang China Telecom On Jul 29, 2022, at 02:04, Acee Lindem (acee) wrote: Speaking as WG Member: Hi Ketan, Thanks for pointing out the similarities. Even after the recent changes, there are still some difference between the drafts which I’ll describe in the baseless comments which follow. For conciseness, I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak). 1. Backward Compatibility – Now that PUA has appropriated the metric mechanisms from UPA, it is also backward compatible. However, PUA still proposes extensions the IGPs to advertise the PUA capabilities and says the nodes may misbehave if they don’t agree on these capabilities. I guess removing these was omitted when the UPA metric mechanisms were appropriated. WAJ] No. the context in the document just describes why and when the LSInfinity is necessary. The usages of LSInfinity in two drafts are different: one(PUA) is to avoid the misbehavior(which is conform to the RFC rules), another(UPA) is to indicate the unreachable information(which is not described in the RFC rules) 1. 2. Receive Router Behavior – For UPA, the unreachable prefix notification is solely for an event signal to be used by other routers in the IGP domain to trigger actions, e.g., BGP PIC excluding the unreachable prefix. PUA is used for the switchover of services as well but is also used to modify persistent state. In section 4, the PUA advertisement will trigger the advertisement of the prefix by an ABR that does have a route to the unreachable prefix advertised by another ABR. [WAJ] Is this one evidence that PUA covers UPA? 2. 3. Advertisement Persistence – PUA is advertised like any other LSA and presumably advertised as long as the prefix is unreachable. Conversely, UPA is an ephemeral LSA that will be withdrawn after enough time is allowed for the event notification to propagate. [WAJ] No. if there is no network update again, the PUA will not be advertised “as long as the prefix is unreachable “. Actually, there is description in the document: “The advertisement of PUAM message should only last one configurable period to allow the services that run on the failure prefixes are switchovered. If one prefix is missed before the PUAM takes effect, the ABR will not declare its absence via the PUAM.” I think you may ignore them. 3. In my opinion, UPA is superior to PUA since it is addresses the original requirement with minimal overhead and changes to the IGP. Even after many revisions, PUA still contains a lot of additional unnecessary overhead and complexity. I think the WG should adopt UPA and not spend any more time on this discussion. [WAJ] From the above responses, I think you should realize that UPA just cover very minor part of the overall PUA solution, then your conclusion should be reverted. Or else, we can compare these two drafts sentences by sentences. Thanks, Acee *From: *Lsr on behalf of Ketan Talaulikar *Date: *Thursday, July 28, 2022 at 2:29 AM *To: *Aijun Wang *Cc: *"Les Ginsberg (ginsberg)" , "draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" , lsr *Subject: *Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement Hi Aijun, Indeed, your draft has done a "pivot" in the latest version with the use of LSInfinity like the UPA proposal. I hope you will do yet another "pivot" to move away from the use of Prefix Originator. IMHO that would also bring the PUA and UPA proposals much closer to each other. Thanks, Ketan On Thu, Jul 28, 2022 at 6:52 AM Aijun Wang <mailto:wangai...@tsinghua.org.cn>> wrote: Hi, Les: I admire you and your comments as usual, but the baseless comments will decrease you
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Hi, Acee: Thanks for your comments, but most of them are indefensible, especially the conclusion. As you have also noticed, UPA mechanism doesn’t consider the network partition scenarios, doesn’t consider how to control the number of advertisement of unreachable messages, doesn’t provide the explicit notification of unreachable statement(as also pointed out Ketan, Bruno etc.), then how you hurry to get the conclusion that UPA is superior to PUA? We have yet mentioned that PUA mechanism has been discussed two years before the UPA solution. More responses are inline. Anyway, I am glad that your comments have some bases, although you misunderstood something. Aijun Wang China Telecom > On Jul 29, 2022, at 02:04, Acee Lindem (acee) wrote: > > Speaking as WG Member: > > Hi Ketan, > > Thanks for pointing out the similarities. Even after the recent changes, > there are still some difference between the drafts which I’ll describe in the > baseless comments which follow. For conciseness, I’ll refer to the drafts as > PUA (Draft Wang) and UPA (Draft Psenak). > > Backward Compatibility – Now that PUA has appropriated the metric mechanisms > from UPA, it is also backward compatible. However, PUA still proposes > extensions the IGPs to advertise the PUA capabilities and says the nodes may > misbehave if they don’t agree on these capabilities. I guess removing these > was omitted when the UPA metric mechanisms were appropriated. WAJ] No. the context in the document just describes why and when the LSInfinity is necessary. The usages of LSInfinity in two drafts are different: one(PUA) is to avoid the misbehavior(which is conform to the RFC rules), another(UPA) is to indicate the unreachable information(which is not described in the RFC rules) > Receive Router Behavior – For UPA, the unreachable prefix notification is > solely for an event signal to be used by other routers in the IGP domain to > trigger actions, e.g., BGP PIC excluding the unreachable prefix. PUA is used > for the switchover of services as well but is also used to modify persistent > state. In section 4, the PUA advertisement will trigger the advertisement of > the prefix by an ABR that does have a route to the unreachable prefix > advertised by another ABR. [WAJ] Is this one evidence that PUA covers UPA? > Advertisement Persistence – PUA is advertised like any other LSA and > presumably advertised as long as the prefix is unreachable. Conversely, UPA > is an ephemeral LSA that will be withdrawn after enough time is allowed for > the event notification to propagate. [WAJ] No. if there is no network update again, the PUA will not be advertised “as long as the prefix is unreachable “. Actually, there is description in the document: “The advertisement of PUAM message should only last one configurable period to allow the services that run on the failure prefixes are switchovered. If one prefix is missed before the PUAM takes effect, the ABR will not declare its absence via the PUAM.” I think you may ignore them. > > In my opinion, UPA is superior to PUA since it is addresses the original > requirement with minimal overhead and changes to the IGP. Even after many > revisions, PUA still contains a lot of additional unnecessary overhead and > complexity. I think the WG should adopt UPA and not spend any more time on > this discussion. > [WAJ] From the above responses, I think you should realize that UPA just cover very minor part of the overall PUA solution, then your conclusion should be reverted. Or else, we can compare these two drafts sentences by sentences. > Thanks, > Acee > > From: Lsr on behalf of Ketan Talaulikar > > Date: Thursday, July 28, 2022 at 2:29 AM > To: Aijun Wang > Cc: "Les Ginsberg (ginsberg)" , > "draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" > , lsr > Subject: Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement > > Hi Aijun, > > Indeed, your draft has done a "pivot" in the latest version with the use of > LSInfinity like the UPA proposal. I hope you will do yet another "pivot" to > move away from the use of Prefix Originator. > > IMHO that would also bring the PUA and UPA proposals much closer to each > other. > > Thanks, > Ketan > > > On Thu, Jul 28, 2022 at 6:52 AM Aijun Wang wrote: > Hi, Les: > > I admire you and your comments as usual, but the baseless comments will > decrease your credits within the WG. Would you like to review the update of > the draft more carefully, then post your comments? Doing this can avoid > misleading some of your followers. > > To facilitate your review, I copied the related contents > again:(https://datatracker.ietf.org/doc/ht
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Hi Acee, I agree with your so-called "baseless comments" on the differences between the two drafts but I still hold some hope for further convergence between the two proposals. Thanks, Ketan On Thu, Jul 28, 2022 at 11:33 PM Acee Lindem (acee) wrote: > Speaking as WG Member: > > > > Hi Ketan, > > > > Thanks for pointing out the similarities. Even after the recent changes, > there are still some difference between the drafts which I’ll describe in > the baseless comments which follow. For conciseness, I’ll refer to the > drafts as PUA (Draft Wang) and UPA (Draft Psenak). > > > >1. Backward Compatibility – Now that PUA has appropriated the metric >mechanisms from UPA, it is also backward compatible. However, PUA still >proposes extensions the IGPs to advertise the PUA capabilities and says the >nodes may misbehave if they don’t agree on these capabilities. I guess >removing these was omitted when the UPA metric mechanisms were >appropriated. >2. Receive Router Behavior – For UPA, the unreachable prefix >notification is solely for an event signal to be used by other routers in >the IGP domain to trigger actions, e.g., BGP PIC excluding the unreachable >prefix. PUA is used for the switchover of services as well but is also >used to modify persistent state. In section 4, the PUA advertisement will >trigger the advertisement of the prefix by an ABR that does have a route to >the unreachable prefix advertised by another ABR. >3. Advertisement Persistence – PUA is advertised like any other LSA >and presumably advertised as long as the prefix is unreachable. Conversely, >UPA is an ephemeral LSA that will be withdrawn after enough time is allowed >for the event notification to propagate. > > > > In my opinion, UPA is superior to PUA since it is addresses the original > requirement with minimal overhead and changes to the IGP. Even after many > revisions, PUA still contains a lot of additional unnecessary overhead and > complexity. I think the WG should adopt UPA and not spend any more time on > this discussion. > > > > Thanks, > > Acee > > > > *From: *Lsr on behalf of Ketan Talaulikar < > ketant.i...@gmail.com> > *Date: *Thursday, July 28, 2022 at 2:29 AM > *To: *Aijun Wang > *Cc: *"Les Ginsberg (ginsberg)" , " > draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" < > draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>, lsr > > *Subject: *Re: [Lsr] Comments on > draft-wang-lsr-prefix-unreachable-annoucement > > > > Hi Aijun, > > > > Indeed, your draft has done a "pivot" in the latest version with the use > of LSInfinity like the UPA proposal. I hope you will do yet another "pivot" > to move away from the use of Prefix Originator. > > > > IMHO that would also bring the PUA and UPA proposals much closer to each > other. > > > > Thanks, > > Ketan > > > > > > On Thu, Jul 28, 2022 at 6:52 AM Aijun Wang > wrote: > > Hi, Les: > > > > I admire you and your comments as usual, but the baseless comments will > decrease your credits within the WG. Would you like to review the update of > the draft more carefully, then post your comments? Doing this can avoid > misleading some of your followers. > > > > To facilitate your review, I copied the related contents again:( > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5 > ) > > > > If not all of nodes within one area support the PUAM capabilities, > >the PUAM message should be advertised with the associated prefix cost > >set to LSInfinity. According to the description in [RFC2328 > <https://datatracker.ietf.org/doc/html/rfc2328>], > >[RFC5305 <https://datatracker.ietf.org/doc/html/rfc5305>] and [RFC5308 > <https://datatracker.ietf.org/doc/html/rfc5308>], the prefix advertised with > such metric value > >will not be considered during the normal SPF computation, then such > >additional information will avoid the misbehavior of the nodes when > >they don't recognize the PUAM message. > > > >If all of nodes within one area support the PUAM capabilites, the > >PUAM message can be safely advertised without the additional > >LSInfinity metric information. > > > > Then, how can the “legacy nodes MUST interpret as meaning reachable.” ? I > wish to hear your explanation. > > > > Aijun Wang > > China Telecom > > > > On Jul 28, 2022, at 06:39, Les Ginsberg (ginsberg) 40cisco@dmarc.ietf.org> wrote: &g
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Speaking as WG Member: Hi Ketan, Thanks for pointing out the similarities. Even after the recent changes, there are still some difference between the drafts which I’ll describe in the baseless comments which follow. For conciseness, I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak). 1. Backward Compatibility – Now that PUA has appropriated the metric mechanisms from UPA, it is also backward compatible. However, PUA still proposes extensions the IGPs to advertise the PUA capabilities and says the nodes may misbehave if they don’t agree on these capabilities. I guess removing these was omitted when the UPA metric mechanisms were appropriated. 2. Receive Router Behavior – For UPA, the unreachable prefix notification is solely for an event signal to be used by other routers in the IGP domain to trigger actions, e.g., BGP PIC excluding the unreachable prefix. PUA is used for the switchover of services as well but is also used to modify persistent state. In section 4, the PUA advertisement will trigger the advertisement of the prefix by an ABR that does have a route to the unreachable prefix advertised by another ABR. 3. Advertisement Persistence – PUA is advertised like any other LSA and presumably advertised as long as the prefix is unreachable. Conversely, UPA is an ephemeral LSA that will be withdrawn after enough time is allowed for the event notification to propagate. In my opinion, UPA is superior to PUA since it is addresses the original requirement with minimal overhead and changes to the IGP. Even after many revisions, PUA still contains a lot of additional unnecessary overhead and complexity. I think the WG should adopt UPA and not spend any more time on this discussion. Thanks, Acee From: Lsr on behalf of Ketan Talaulikar Date: Thursday, July 28, 2022 at 2:29 AM To: Aijun Wang Cc: "Les Ginsberg (ginsberg)" , "draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" , lsr Subject: Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement Hi Aijun, Indeed, your draft has done a "pivot" in the latest version with the use of LSInfinity like the UPA proposal. I hope you will do yet another "pivot" to move away from the use of Prefix Originator. IMHO that would also bring the PUA and UPA proposals much closer to each other. Thanks, Ketan On Thu, Jul 28, 2022 at 6:52 AM Aijun Wang mailto:wangai...@tsinghua.org.cn>> wrote: Hi, Les: I admire you and your comments as usual, but the baseless comments will decrease your credits within the WG. Would you like to review the update of the draft more carefully, then post your comments? Doing this can avoid misleading some of your followers. To facilitate your review, I copied the related contents again:(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5) If not all of nodes within one area support the PUAM capabilities, the PUAM message should be advertised with the associated prefix cost set to LSInfinity. According to the description in [RFC2328<https://datatracker.ietf.org/doc/html/rfc2328>], [RFC5305<https://datatracker.ietf.org/doc/html/rfc5305>] and [RFC5308<https://datatracker.ietf.org/doc/html/rfc5308>], the prefix advertised with such metric value will not be considered during the normal SPF computation, then such additional information will avoid the misbehavior of the nodes when they don't recognize the PUAM message. If all of nodes within one area support the PUAM capabilites, the PUAM message can be safely advertised without the additional LSInfinity metric information. Then, how can the “legacy nodes MUST interpret as meaning reachable.” ? I wish to hear your explanation. Aijun Wang China Telecom On Jul 28, 2022, at 06:39, Les Ginsberg (ginsberg) mailto:40cisco@dmarc.ietf.org>> wrote: (Preamble: All of what I am going to say I have said many times before – on the list – off the list – in private conversations – in WG meetings… I don’t say this to start a discussion with the WG authors – it seems clear that we don’t agree and have no path to agreement. My purpose in saying this is to respond to the ongoing existence of this draft and offering my opinion as to what action the WG should take.) The mechanism defined in this draft is broken. Not only is it not backwards compatible – the PUA advertisements will be misinterpreted to mean the exact opposite of what is intended i.e., the intent is to signal that a prefix is unreachable, but you do so by using an advertisement which legacy nodes MUST interpret as meaning reachable. This is simply broken and should not be done. The authors deserve credit for bringing the attention of the WG to the problem space – but the solution offered is not deployable. Given the long period of time during which this draft has been published and the many t
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Hi Aijun, Indeed, your draft has done a "pivot" in the latest version with the use of LSInfinity like the UPA proposal. I hope you will do yet another "pivot" to move away from the use of Prefix Originator. IMHO that would also bring the PUA and UPA proposals much closer to each other. Thanks, Ketan On Thu, Jul 28, 2022 at 6:52 AM Aijun Wang wrote: > > > Hi, Les: > > I admire you and your comments as usual, but the baseless comments will > decrease your credits within the WG. Would you like to review the update of > the draft more carefully, then post your comments? Doing this can avoid > misleading some of your followers. > > To facilitate your review, I copied the related contents again:( > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5 > ) > > > If not all of nodes within one area support the PUAM capabilities, >the PUAM message should be advertised with the associated prefix cost >set to LSInfinity. According to the description in [RFC2328 > <https://datatracker.ietf.org/doc/html/rfc2328>], >[RFC5305 <https://datatracker.ietf.org/doc/html/rfc5305>] and [RFC5308 > <https://datatracker.ietf.org/doc/html/rfc5308>], the prefix advertised with > such metric value >will not be considered during the normal SPF computation, then such >additional information will avoid the misbehavior of the nodes when >they don't recognize the PUAM message. > >If all of nodes within one area support the PUAM capabilites, the >PUAM message can be safely advertised without the additional >LSInfinity metric information. > > > Then, how can the “legacy nodes MUST interpret as meaning reachable.” ? I > wish to hear your explanation. > > Aijun Wang > China Telecom > > On Jul 28, 2022, at 06:39, Les Ginsberg (ginsberg) 40cisco@dmarc.ietf.org> wrote: > > > > (Preamble: All of what I am going to say I have said many times before – > on the list – off the list – in private conversations – in WG meetings… > > I don’t say this to start a discussion with the WG authors – it seems > clear that we don’t agree and have no path to agreement. > > My purpose in saying this is to respond to the ongoing existence of this > draft and offering my opinion as to what action the WG should take.) > > > > The mechanism defined in this draft is broken. Not only is it not > backwards compatible – the PUA advertisements will be misinterpreted to > mean the exact opposite of what is intended i.e., the intent is to signal > that a prefix is unreachable, but you do so by using an advertisement which > legacy nodes MUST interpret as meaning reachable. This is simply broken and > should not be done. > > > > The authors deserve credit for bringing the attention of the WG to the > problem space – but the solution offered is not deployable. Given the long > period of time during which this draft has been published and the many > times it has been presented/discussed in the WG I think it is now time to > say thank you to the authors for their work, but the WG is not interested > in adopting this draft. > > > >Les > > > > > > *From:* Lsr *On Behalf Of * Ketan Talaulikar > *Sent:* Wednesday, July 27, 2022 1:36 AM > *To:* draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org > *Cc:* lsr > *Subject:* [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement > > > > Hello Authors, > > > > I am sharing some comments on the latest version of this document since we > seem to have a packed agenda in LSR this time. > > > > 1) I notice that in the latest update of the draft, there is a big change > to start using LSInfinity for indicating prefix unreachability (similar > to draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a > degree of convergence between the two drafts. > > > > 2) However, I then question the motivation of the authors to continue with > the bad design of overloading Prefix Originator and the added capability > stuff on top. I don't wish to repeat why that design was an absolute NO-GO > for me and I am glad to see the authors acknowledge the problem with > misrouting by implementations not supporting this specification. So I don't > see the point of still retaining all that. > > > > Thanks, > > Ketan > > > ___ > 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] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Hi, Les: I admire you and your comments as usual, but the baseless comments will decrease your credits within the WG. Would you like to review the update of the draft more carefully, then post your comments? Doing this can avoid misleading some of your followers. To facilitate your review, I copied the related contents again:(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5) If not all of nodes within one area support the PUAM capabilities, the PUAM message should be advertised with the associated prefix cost set to LSInfinity. According to the description in [RFC2328], [RFC5305] and [RFC5308], the prefix advertised with such metric value will not be considered during the normal SPF computation, then such additional information will avoid the misbehavior of the nodes when they don't recognize the PUAM message. If all of nodes within one area support the PUAM capabilites, the PUAM message can be safely advertised without the additional LSInfinity metric information. Then, how can the “legacy nodes MUST interpret as meaning reachable.” ? I wish to hear your explanation. Aijun Wang China Telecom > On Jul 28, 2022, at 06:39, Les Ginsberg (ginsberg) > wrote: > > (Preamble: All of what I am going to say I have said many times before – on > the list – off the list – in private conversations – in WG meetings… > I don’t say this to start a discussion with the WG authors – it seems clear > that we don’t agree and have no path to agreement. > My purpose in saying this is to respond to the ongoing existence of this > draft and offering my opinion as to what action the WG should take.) > > The mechanism defined in this draft is broken. Not only is it not backwards > compatible – the PUA advertisements will be misinterpreted to mean the exact > opposite of what is intended i.e., the intent is to signal that a prefix is > unreachable, but you do so by using an advertisement which legacy nodes MUST > interpret as meaning reachable. This is simply broken and should not be done. > > The authors deserve credit for bringing the attention of the WG to the > problem space – but the solution offered is not deployable. Given the long > period of time during which this draft has been published and the many times > it has been presented/discussed in the WG I think it is now time to say thank > you to the authors for their work, but the WG is not interested in adopting > this draft. > >Les > > > From: Lsr On Behalf Of Ketan Talaulikar > Sent: Wednesday, July 27, 2022 1:36 AM > To: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org > Cc: lsr > Subject: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement > > Hello Authors, > > I am sharing some comments on the latest version of this document since we > seem to have a packed agenda in LSR this time. > > 1) I notice that in the latest update of the draft, there is a big change to > start using LSInfinity for indicating prefix unreachability (similar to > draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a > degree of convergence between the two drafts. > > 2) However, I then question the motivation of the authors to continue with > the bad design of overloading Prefix Originator and the added capability > stuff on top. I don't wish to repeat why that design was an absolute NO-GO > for me and I am glad to see the authors acknowledge the problem with > misrouting by implementations not supporting this specification. So I don't > see the point of still retaining all that. > > Thanks, > Ketan > > ___ > 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] Comments on draft-wang-lsr-prefix-unreachable-annoucement
+1 Sent from my iPhone > On 27.07.2022, at 23:39, Les Ginsberg (ginsberg) > wrote: > > > (Preamble: All of what I am going to say I have said many times before – on > the list – off the list – in private conversations – in WG meetings… > I don’t say this to start a discussion with the WG authors – it seems clear > that we don’t agree and have no path to agreement. > My purpose in saying this is to respond to the ongoing existence of this > draft and offering my opinion as to what action the WG should take.) > > The mechanism defined in this draft is broken. Not only is it not backwards > compatible – the PUA advertisements will be misinterpreted to mean the exact > opposite of what is intended i.e., the intent is to signal that a prefix is > unreachable, but you do so by using an advertisement which legacy nodes MUST > interpret as meaning reachable. This is simply broken and should not be done. > > The authors deserve credit for bringing the attention of the WG to the > problem space – but the solution offered is not deployable. Given the long > period of time during which this draft has been published and the many times > it has been presented/discussed in the WG I think it is now time to say thank > you to the authors for their work, but the WG is not interested in adopting > this draft. > >Les > > > From: Lsr On Behalf Of Ketan Talaulikar > Sent: Wednesday, July 27, 2022 1:36 AM > To: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org > Cc: lsr > Subject: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement > > Hello Authors, > > I am sharing some comments on the latest version of this document since we > seem to have a packed agenda in LSR this time. > > 1) I notice that in the latest update of the draft, there is a big change to > start using LSInfinity for indicating prefix unreachability (similar to > draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a > degree of convergence between the two drafts. > > 2) However, I then question the motivation of the authors to continue with > the bad design of overloading Prefix Originator and the added capability > stuff on top. I don't wish to repeat why that design was an absolute NO-GO > for me and I am glad to see the authors acknowledge the problem with > misrouting by implementations not supporting this specification. So I don't > see the point of still retaining all that. > > Thanks, > Ketan > > ___ > 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] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Cogent analysis of the situation Sent from my iPhone On Jul 27, 2022, at 6:39 PM, Les Ginsberg (ginsberg) wrote: [External Email. Be cautious of content] (Preamble: All of what I am going to say I have said many times before – on the list – off the list – in private conversations – in WG meetings… I don’t say this to start a discussion with the WG authors – it seems clear that we don’t agree and have no path to agreement. My purpose in saying this is to respond to the ongoing existence of this draft and offering my opinion as to what action the WG should take.) The mechanism defined in this draft is broken. Not only is it not backwards compatible – the PUA advertisements will be misinterpreted to mean the exact opposite of what is intended i.e., the intent is to signal that a prefix is unreachable, but you do so by using an advertisement which legacy nodes MUST interpret as meaning reachable. This is simply broken and should not be done. The authors deserve credit for bringing the attention of the WG to the problem space – but the solution offered is not deployable. Given the long period of time during which this draft has been published and the many times it has been presented/discussed in the WG I think it is now time to say thank you to the authors for their work, but the WG is not interested in adopting this draft. Les From: Lsr On Behalf Of Ketan Talaulikar Sent: Wednesday, July 27, 2022 1:36 AM To: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org Cc: lsr Subject: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement Hello Authors, I am sharing some comments on the latest version of this document since we seem to have a packed agenda in LSR this time. 1) I notice that in the latest update of the draft, there is a big change to start using LSInfinity for indicating prefix unreachability (similar to draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a degree of convergence between the two drafts. 2) However, I then question the motivation of the authors to continue with the bad design of overloading Prefix Originator and the added capability stuff on top. I don't wish to repeat why that design was an absolute NO-GO for me and I am glad to see the authors acknowledge the problem with misrouting by implementations not supporting this specification. So I don't see the point of still retaining all that. Thanks, Ketan ___ Lsr mailing list Lsr@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!BOlSdK7Bi4AiMHOkDAkQiJpIOJfYNcj0qrpU2SCoNERRIGtQSK7WvmUsq1G2qQWfkMk71PBRPJXzRZFS0M9DoNqIeHOMS_U$ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
(Preamble: All of what I am going to say I have said many times before – on the list – off the list – in private conversations – in WG meetings… I don’t say this to start a discussion with the WG authors – it seems clear that we don’t agree and have no path to agreement. My purpose in saying this is to respond to the ongoing existence of this draft and offering my opinion as to what action the WG should take.) The mechanism defined in this draft is broken. Not only is it not backwards compatible – the PUA advertisements will be misinterpreted to mean the exact opposite of what is intended i.e., the intent is to signal that a prefix is unreachable, but you do so by using an advertisement which legacy nodes MUST interpret as meaning reachable. This is simply broken and should not be done. The authors deserve credit for bringing the attention of the WG to the problem space – but the solution offered is not deployable. Given the long period of time during which this draft has been published and the many times it has been presented/discussed in the WG I think it is now time to say thank you to the authors for their work, but the WG is not interested in adopting this draft. Les From: Lsr On Behalf Of Ketan Talaulikar Sent: Wednesday, July 27, 2022 1:36 AM To: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org Cc: lsr Subject: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement Hello Authors, I am sharing some comments on the latest version of this document since we seem to have a packed agenda in LSR this time. 1) I notice that in the latest update of the draft, there is a big change to start using LSInfinity for indicating prefix unreachability (similar to draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a degree of convergence between the two drafts. 2) However, I then question the motivation of the authors to continue with the bad design of overloading Prefix Originator and the added capability stuff on top. I don't wish to repeat why that design was an absolute NO-GO for me and I am glad to see the authors acknowledge the problem with misrouting by implementations not supporting this specification. So I don't see the point of still retaining all that. Thanks, Ketan ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Hi Aijun, Please check inline below. On Wed, Jul 27, 2022 at 4:13 PM Aijun Wang wrote: > Hi, Ketan: > > > > We have discussed with Bruno offline for the possibilities of defining new > flag to indicate the unreachable status explicitly. > > It’s possible, but the challenge is that for OSPFv3, currently, there only > one bit unassigned ( > https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4). > It may need more works to expand the flag bits for OSPFv3. > KT> There is this individual document for OSPF which helps extend the space for prefix flags ( https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/). So we can do the right thing here. > And, I can’t see there is significant differences between using the > originator field and the flag bits to accomplish such aim. > > > > Would you like to state more clearly why the NULL value of originator > can’t be used to indicate the unreachability explicitly? From my POV, if > the prefix became unreachable, there is no originator advertise it, isn’t > it? > KT> There is a difference between the use of Prefix flags vs Prefix Originator. Semantics are important in protocol encoding. IMHO we should not just overload and stuff things around. > > > Anyway, this can be discussed further later after the adoption. > KT> IMHO the draft is not yet ready for adoption in its current state. Thanks, Ketan > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *发件人:* Ketan Talaulikar [mailto:ketant.i...@gmail.com] > *发送时间:* 2022年7月27日 17:45 > *收件人:* Aijun Wang > *抄送:* draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr < > lsr@ietf.org> > *主题:* Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement > > > > Hi Aijun, > > > > Please check inline below for a quick response. > > > > On Wed, Jul 27, 2022 at 2:55 PM Aijun Wang > wrote: > > Hi, Ketan: > > > > Thanks for your comments. But I should correct some of them: > > 1) In the updated version, the indication of prefix unreachability is > still the “NULL” value of prefix originator, not the LSInfinity. > > KT> Right and I am suggesting you go one step further and remove all that > prefix originator "business" :-) > > > > 2) The LSInfinity is used only for avoiding the misrouting by > implementation not support this implementation, as you have also pointed > out. As pointed out also in the draft, when all the nodes within the area > support such capabilities, the LSInfinity value can be ignored: > > > > KT> Well, as indicated, the use of the prefix originator for this purpose > is broken in my view. The use of LSInfinity is helpful to navigate through > backward compatibility issues. With prefix originator aspects removed, we > don't need the capability anymore. What comes out at the other end of this > "pivot" for draft-wang is much similar to the other proposal ... and this > IMHO is good. > > > > > > “If not all of nodes within one area support the PUAM capabilities, > >the PUAM message should be advertised with the associated prefix cost > >set to LSInfinity. According to the description in [RFC2328 > <https://datatracker.ietf.org/doc/html/rfc2328>], > >[RFC5305 <https://datatracker.ietf.org/doc/html/rfc5305>] and [RFC5308 > <https://datatracker.ietf.org/doc/html/rfc5308>], the prefix advertised with > such metric value > >will not be considered during the normal SPF computation, then such > >additional information will avoid the misbehavior of the nodes when > >they don't recognize the PUAM message. > > > >If all of nodes within one area support the PUAM capabilites, the > >PUAM message can be safely advertised without the additional > >LSInfinity metric information.” > > > > > > We are glad to cooperate with Peter to forward the solution, but want to > say LSInfinity only can’t be used to indicate the unreachable > information, we need some explicit indication method. > > > > KT> There is some value in having an explicit indication in addition to > the use of LSInfinity in draft-ppsenak. Perhaps a prefix attribute flag as > was already suggested to the authors of draft-ppsenak ( > https://mailarchive.ietf.org/arch/msg/lsr/Q9wU3Bo1uzhPd5C7bT_WE7k_3JI/). > But certainly not the prefix originator as proposed by draft-wang. > > > > Thanks, > > Ketan > > > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *发件人:* lsr-boun...@ietf.org [mailto:ls
Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Hi Aijun, Please check inline below for a quick response. On Wed, Jul 27, 2022 at 2:55 PM Aijun Wang wrote: > Hi, Ketan: > > > > Thanks for your comments. But I should correct some of them: > > 1) In the updated version, the indication of prefix unreachability is > still the “NULL” value of prefix originator, not the LSInfinity. > KT> Right and I am suggesting you go one step further and remove all that prefix originator "business" :-) > 2) The LSInfinity is used only for avoiding the misrouting by > implementation not support this implementation, as you have also pointed > out. As pointed out also in the draft, when all the nodes within the area > support such capabilities, the LSInfinity value can be ignored: > KT> Well, as indicated, the use of the prefix originator for this purpose is broken in my view. The use of LSInfinity is helpful to navigate through backward compatibility issues. With prefix originator aspects removed, we don't need the capability anymore. What comes out at the other end of this "pivot" for draft-wang is much similar to the other proposal ... and this IMHO is good. > > > “If not all of nodes within one area support the PUAM capabilities, > >the PUAM message should be advertised with the associated prefix cost > >set to LSInfinity. According to the description in [RFC2328 > <https://datatracker.ietf.org/doc/html/rfc2328>], > >[RFC5305 <https://datatracker.ietf.org/doc/html/rfc5305>] and [RFC5308 > <https://datatracker.ietf.org/doc/html/rfc5308>], the prefix advertised with > such metric value > >will not be considered during the normal SPF computation, then such > >additional information will avoid the misbehavior of the nodes when > >they don't recognize the PUAM message. > > > >If all of nodes within one area support the PUAM capabilites, the > >PUAM message can be safely advertised without the additional > >LSInfinity metric information.” > > > > > > We are glad to cooperate with Peter to forward the solution, but want to > say LSInfinity only can’t be used to indicate the unreachable information, > we need some explicit indication method. > KT> There is some value in having an explicit indication in addition to the use of LSInfinity in draft-ppsenak. Perhaps a prefix attribute flag as was already suggested to the authors of draft-ppsenak ( https://mailarchive.ietf.org/arch/msg/lsr/Q9wU3Bo1uzhPd5C7bT_WE7k_3JI/). But certainly not the prefix originator as proposed by draft-wang. Thanks, Ketan > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *发件人:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *代表 *Ketan > Talaulikar > *发送时间:* 2022年7月27日 16:36 > *收件人:* draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org > *抄送:* lsr > *主题:* [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement > > > > Hello Authors, > > > > I am sharing some comments on the latest version of this document since we > seem to have a packed agenda in LSR this time. > > > > 1) I notice that in the latest update of the draft, there is a big change > to start using LSInfinity for indicating prefix unreachability (similar > to draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a > degree of convergence between the two drafts. > > > > 2) However, I then question the motivation of the authors to continue with > the bad design of overloading Prefix Originator and the added capability > stuff on top. I don't wish to repeat why that design was an absolute NO-GO > for me and I am glad to see the authors acknowledge the problem with > misrouting by implementations not supporting this specification. So I don't > see the point of still retaining all that. > > > > Thanks, > > Ketan > > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
Hello Authors, I am sharing some comments on the latest version of this document since we seem to have a packed agenda in LSR this time. 1) I notice that in the latest update of the draft, there is a big change to start using LSInfinity for indicating prefix unreachability (similar to draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a degree of convergence between the two drafts. 2) However, I then question the motivation of the authors to continue with the bad design of overloading Prefix Originator and the added capability stuff on top. I don't wish to repeat why that design was an absolute NO-GO for me and I am glad to see the authors acknowledge the problem with misrouting by implementations not supporting this specification. So I don't see the point of still retaining all that. Thanks, Ketan ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
