[Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Acee:

 

It‘s you that repeat the FALSE statements. What I can do is to give you the 
FACT again.

Please see inline below for the response to your FALSE statements.

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: Acee Lindem [mailto:acee.i...@gmail.com] 
发送时间: 2023年9月6日 20:44
收件人: Aijun Wang 
抄送: Robert Raszuk ; Les Ginsberg (ginsberg) 
; Huzhibo 
; Peter Psenak ; 
linchangwang ; lsr 
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04

 

Hi Aijun, 

 

I think we are repeating ourselves here. However, let me add a couple points. 
The fact that you added the BGP PIC use case to your draft when the WG 
indicated that was the problem to be solved doesn’t make you the owner of the 
use case. 

[WAJ] FALSE Statement.

I have replied you for such FALSE assertions at 
https://mailarchive.ietf.org/arch/msg/lsr/I1Hb28F1Fg8GrPTynJa1ZYqtY0Y/ (Aug.25 
2023) , but you raised it again. 

Please provide the fact that “WG indicated that was the problem to be solved” 
before our proposal.  For your convenience, I replied again in detail below:

 

Please read carefully the description in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-00#section-3
 (Proposed in Oct.24, 2019)

"In another situation, assume the BGP session is built between Node S2

   and T2, via Ps2 and Pt2 respectively.  If Node S2 within area 1

   become unreachable, the unreachable information can't be advertised

   to Node T2 because the summary behaviour on border router R1/R3.  The

   BGP session between S1 and T2 will be kept until the BGP keepalive

   timeout or other detection mechanism takes effect.  During this

   period, the BGP traffic to Node S2 will be in black hole."

 

Additionally, the fact that you were offered authorship on the draft under 
adoption is a recognition that you did have a draft the addressed IGP 
unreachability. However, you declined.

[WAJ] We provide first the use cases, insist that the explicit signaling 
solution is the direction and lead the discussions within LSR WG, the adoption 
draft should be based on 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement,
 not the follower.

 

Finally, even after appropriating some of the elements of the draft under 
adoption (e.g., unreachable metrics and configuration of LSA life) your draft 
is now a superset of the former draft and, IMO, unimplementable.

 

[WAJ] FALSE Statement. 

For the configuration of LSA Life, I have replied you at 
https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/, please 
do not repeat it again. For your convenience, let me emphasize the FACT again:

1) The description about the short lived notification in  

 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7
 was on March 26, 2021

2) The similar description, even the 00 version of  
 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ was 
submitted on July 5, 2021

Then, which draft appropriates which draft?

 

For the unreachable metrics, the usages of the two drafts are different: 
draft-ppsenak used such information as implicit signaling(“This functionality 
can be used to advertise a prefix (IPv4 or IPv6) in a manner which indicates 
that reachability has been lost”), we used it to solve the interoperable issue 
with the legacy router(“the prefix advertised with such metric value will not 
be considered during the normal SPF computation)” which is the original usage 
that defined in relevant RFCs)

It is after our insists and intense discussions, draft-ppsenak switched to the 
explicit signaling(by defining new flags, which is still arguable). It is now 
the superset of the implicit signaling and explicit signaling, which is 
unnecessary.

 

Thanks,

Acee 

 





On Sep 6, 2023, at 01:56, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Hi, Acee:

 

AGAIN, before making some assertions, please check the following fact:

Have you noticed the 00 version of  
 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ was 
submitted on July 5, 2021?

But the description about the short lived notification in  

 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7
 was on March 26, 2021.

Then, which draft was the first?

 

For the adoption call or merge efforts, I think the WG should consider the 
following facts:

1) Which draft is the first to provide the use cases? 

2) Which draft is the first to propose 

Re: [Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Peter Psenak]

Aijun,

On 06/09/2023 11:02, Aijun Wang wrote:



My proposal is that we postpone the adoption of this draft, and discuss 
offline the merger document on the coming IETF118 meeting.


I want to be very clear, there is nothing to be merged.

regards,
Peter


Then, we can submit the merged document to the LSR WG for adoption call.



my 2c,
Peter





On 06/09/2023 07:56, Aijun Wang wrote:

Hi, Acee:
AGAIN, before making some assertions, please check the following fact:
Have you noticed the 00 version of 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/  was submitted on July 5, 2021?
But the description about the short lived notification in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7  was on March 26, 2021.

Then, which draft was the first?
For the adoption call or merge efforts, I think the WG should 
consider the following facts:

1)Which draft is the first to provide the use cases?
2)Which draft is the first to propose explicit signaling for 
unreachable information?

3)Which draft is the first to propose short lived notification?
4)Which explicit signaling mechanism is simpler?
5)Which draft provides more mechanisms to cover more scenarios?
The base document should be selected based on the answers of the 
above questions.
Select the base document doesn’t mean that it can’t be changed before 
the adoption(I haven’t said “Without Change” is the merge condition).
Actually, we welcome more authors to join us to finalize the document 
and solution.
As one of the most important WG within IETF, I think LSR WG should 
respect the original contributions to the WG.
It is too hurry to consider or adopt only the draft that you prefer, 
especially the follower draft.

Best Regards
Aijun Wang
China Telecom
*发件人:*lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *代表 
*Acee Lindem

*发送时间:*2023年9月6日0:56
*收件人:*Aijun Wang 
*抄送:*Robert Raszuk ; Les Ginsberg (ginsberg) 
; Huzhibo 
; Peter Psenak 
; linchangwang ; lsr 

*主题:*Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

Hi Aijun,
When the WG discussion first indicated that this was a use case that 
needed to be addressed, I don’t dispute that you immediately added it 
to your draft.
I have no doubt you would have purported support of any use case 
under discussion.
However, the first draft to address this use case with a short-lived 
notification was 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ 
Based on WG feedback and collaboration of multiple vendors, this 
draft evolved to draft-ppsenak-lsr-igp-ureach-prefix-announce.
While you’ve incorporated elements of the draft under discussion, 
your draft still includes pieces (sometimes conflicting) from 
previous use cases.
There was an effort to merge the drafts but you declined unless your 
draft was used (without change) as the base. I’m not sure your 
motivation.

Thanks,
Acee
   On Sep 1, 2023, at 20:25, Aijun Wang mailto:wangai...@tsinghua.org.cn>> wrote:
   Hi, Acee:
   Act as LSR chair, I think you should be more responsible to make any
   unfounded assertions:
   We have described the previous statements in
   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7
 
,
 March 26, 2021, one year before the 00 version of draft-ppsenak(March 25,2022)
   Then, which draft copy or incorporate which draft?
   Aijun Wang
   China Telecom
   On Sep 1, 2023, at 20:05, Acee Lindem mailto:acee.i...@gmail.com>> wrote:
   Hi Aijun,
   On Aug 31, 2023, at 23:36, Aijun Wang
   mailto:wangai...@tsinghua.org.cn>> wrote:
   Hi，Acee:
   Please
   
readhttps://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7
 
before
 making misguide assertions:
   “The advertisement of PUAM message should only last one
   configurable period to allow the services that run on the
   failure prefixes are switchovered.”
   I guess I haven’t kept up with all the elements of the draft
   under adoption that you continue to incorporate into your draft.
   This has been a continuing theme since initial discussed of the
   application signaling use case. While I have no interest in
   improving your draft, making the LSP/LSA short-lived conflicts
   with the other scenarios your draft purports to address.
   Acee
   Best Regards
   Aijun Wang

Re: [Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Peter:Aijun WangChina TelecomOn Sep 6, 2023, at 15:57, Peter Psenak  wrote:Aijun,WG adoption should be done based on the draft content, the quality of the solution it describes and not based on the draft age or order.[WAJ] Not exactly. We should also respect the original contributions.Multiple people have pointed out over the years that the solution that you propose in your draft - e.g. using router-id of 0 to indicate the unreachability is broken and lacks the backward compatibility aspect. Your original draft did NOT include the unreachable metric and even though you added it later (way after it was proposed in the other draft), your draft still uses the original router-id 0 idea. The fact that you need the PUAM Capabilities Announcement in your draft speaks for itself.[WAJ] The reason that we keep the “PUAM Capabilities Announcement” is that we want to fade-out the usage of “LSInfinity” Metric within the network,  as described in the draft: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 capabilities, the PUAM message can be safely advertised without the additional LSInfinity metric information.In the latest version of your draft, you have stated also that there maybe other cases to use such metrics:Even though in all cases the treatment of such metric, or NU-bit, is specified for IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix was advertised in order to signal unreachability is required to distinguish it from other cases where the prefix with such metric is advertised.In your proposal, the LSInfinity metric must be set even all the nodes within the area have the capabilities to understand the explicit signaling mechanism. There will be more confusions when other cases of LSInfinity usage proposed.As explained previously, set the existing original router id to NULL is one simple, uniform way to express unreachable information for OSPFv2/v3 and IS-IS. We needn’t find the different places to define and flag it for different protocol. Isn’t it more easier for the implementation?It’s also straightforward to understand.Though you may have been the first one to try to solve the problem in the IETF draft, your solution is still incorrect. As a result of your inability to listen to the comments an alternative draft was written that is technically superior, backward compatible, has wide support from vendors as well as operators, including ones that were originally co-authors on your draft and decided to join the alternate draft based on its technical advantages, has been implemented and deployed in the field.[WAJ]There are other reasons for the switch over of co-author, I think we needn’t expand or refer to it. The standard is not the technical implementation of one company. The standard should look forward further the scenarios, deployment considerations and solutions coverages.As a matter of fact, I have invited you to join our draft several times, but you refused. You insisted on pushing your draft.[WAJ] I have proposed several times the merger of two drafts, we can discuss the contents and structure of the converged document. It’s pity that we missed the IETF117 on-site meeting. But it’s also hurry to put forward only your draft when we consider the history, contributions and similarities of two proposals.My proposal is that we postpone the adoption of this draft, and discuss offline the merger document on the coming IETF118 meeting. Then, we can submit the merged document to the LSR WG for adoption call.my 2c,PeterOn 06/09/2023 07:56, Aijun Wang wrote:Hi, Acee:AGAIN, before making some assertions, please check the following fact:Have you noticed the 00 version of https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/  was submitted on July 5, 2021?But the description about the short lived notification in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7  was on March 26, 2021.Then, which draft was the first?For the adoption call or merge efforts, I think the WG should consider the following facts:1)Which draft is the first to provide the use cases?2)Which draft is the first to propose explicit signaling for unreachable information?3)Which draft is the first to propose short lived notification?4)Which explicit signaling mechanism is simpler?5)Which draft provides more mechanisms to cover more scenarios?The base document should be selected based on the answers of the above questions.Select the base document doesn’t mean that it can’t be changed before the adoption(I haven’t said 

Re: [Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Peter Psenak]

Aijun,

WG adoption should be done based on the draft content, the quality of 
the solution it describes and not based on the draft age or order.


Multiple people have pointed out over the years that the solution that 
you propose in your draft - e.g. using router-id of 0 to indicate the 
unreachability is broken and lacks the backward compatibility aspect. 
Your original draft did NOT include the unreachable metric and even 
though you added it later (way after it was proposed in the other 
draft), your draft still uses the original router-id 0 idea. The fact 
that you need the PUAM Capabilities Announcement in your draft speaks 
for itself.


Though you may have been the first one to try to solve the problem in 
the IETF draft, your solution is still incorrect. As a result of your 
inability to listen to the comments an alternative draft was written 
that is technically superior, backward compatible, has wide support from 
vendors as well as operators, including ones that were originally 
co-authors on your draft and decided to join the alternate draft based 
on its technical advantages, has been implemented and deployed in the field.


As a matter of fact, I have invited you to join our draft several times, 
but you refused. You insisted on pushing your draft.


my 2c,
Peter





On 06/09/2023 07:56, Aijun Wang wrote:

Hi, Acee:

AGAIN, before making some assertions, please check the following fact:

Have you noticed the 00 version of 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/  was submitted on July 5, 2021?


But the description about the short lived notification in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7  was on March 26, 2021.


Then, which draft was the first?

For the adoption call or merge efforts, I think the WG should consider 
the following facts:


1)Which draft is the first to provide the use cases?

2)Which draft is the first to propose explicit signaling for unreachable 
information?


3)Which draft is the first to propose short lived notification?

4)Which explicit signaling mechanism is simpler?

5)Which draft provides more mechanisms to cover more scenarios?

The base document should be selected based on the answers of the above 
questions.


Select the base document doesn’t mean that it can’t be changed before 
the adoption(I haven’t said “Without Change” is the merge condition).


Actually, we welcome more authors to join us to finalize the document 
and solution.


As one of the most important WG within IETF, I think LSR WG should 
respect the original contributions to the WG.


It is too hurry to consider or adopt only the draft that you prefer, 
especially the follower draft.


Best Regards

Aijun Wang

China Telecom

*发件人:*lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *代表 *Acee 
Lindem

*发送时间:*2023年9月6日0:56
*收件人:*Aijun Wang 
*抄送:*Robert Raszuk ; Les Ginsberg (ginsberg) 
; Huzhibo 
; Peter Psenak ; 
linchangwang ; lsr 
*主题:*Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04


Hi Aijun,

When the WG discussion first indicated that this was a use case that 
needed to be addressed, I don’t dispute that you immediately added it to 
your draft.


I have no doubt you would have purported support of any use case under 
discussion.


However, the first draft to address this use case with a short-lived 
notification was 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ 


Based on WG feedback and collaboration of multiple vendors, this draft 
evolved to draft-ppsenak-lsr-igp-ureach-prefix-announce.


While you’ve incorporated elements of the draft under discussion, your 
draft still includes pieces (sometimes conflicting) from previous use cases.


There was an effort to merge the drafts but you declined unless your 
draft was used (without change) as the base. I’m not sure your motivation.


Thanks,

Acee



On Sep 1, 2023, at 20:25, Aijun Wang mailto:wangai...@tsinghua.org.cn>> wrote:

Hi, Acee:

Act as LSR chair, I think you should be more responsible to make any
unfounded assertions:

We have described the previous statements in


https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7
 
,
 March 26, 2021, one year before the 00 version of draft-ppsenak(March 25,2022)

Then, which draft copy or incorporate which draft?

Aijun Wang

China Telecom



On Sep 1, 2023, at 20:05, Acee Lindem mailto:acee.i...@gmail.com>> wrote:

Hi Aijun,



On Aug 31, 

[Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Acee:

 

AGAIN, before making some assertions, please check the following fact:

Have you noticed the 00 version of 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ was 
submitted on July 5, 2021?

But the description about the short lived notification in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7
 was on March 26, 2021.

Then, which draft was the first?

 

For the adoption call or merge efforts, I think the WG should consider the 
following facts:

1) Which draft is the first to provide the use cases? 

2) Which draft is the first to propose explicit signaling for unreachable 
information?

3) Which draft is the first to propose short lived notification?

4) Which explicit signaling mechanism is simpler?

5) Which draft provides more mechanisms to cover more scenarios?

 

The base document should be selected based on the answers of the above 
questions. 

Select the base document doesn’t mean that it can’t be changed before the 
adoption(I haven’t said “Without Change” is the merge condition). 

Actually, we welcome more authors to join us to finalize the document and 
solution.

 

As one of the most important WG within IETF, I think LSR WG should respect the 
original contributions to the WG.

It is too hurry to consider or adopt only the draft that you prefer, especially 
the follower draft.

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年9月6日 0:56
收件人: Aijun Wang 
抄送: Robert Raszuk ; Les Ginsberg (ginsberg) 
; Huzhibo 
; Peter Psenak ; 
linchangwang ; lsr 
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04

 

 

Hi Aijun, 

 

When the WG discussion first indicated that this was a use case that needed to 
be addressed, I don’t dispute that you immediately added it to your draft. 

I have no doubt you would have purported support of any use case under 
discussion. 

 

However, the first draft to address this use case with a short-lived 
notification was  
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/

Based on WG feedback and collaboration of multiple vendors, this draft evolved 
to draft-ppsenak-lsr-igp-ureach-prefix-announce. 

 

While you’ve incorporated elements of the draft under discussion, your draft 
still includes pieces (sometimes conflicting) from previous use cases.

 

There was an effort to merge the drafts but you declined unless your draft was 
used (without change) as the base. I’m not sure your motivation. 

 

Thanks,

Acee

 

 





On Sep 1, 2023, at 20:25, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Hi, Acee:

 

Act as LSR chair, I think you should be more responsible to make any unfounded 
assertions:

 

We have described the previous statements in

https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7,
 March 26, 2021, one year before the 00 version of draft-ppsenak(March 25,2022)

 

Then, which draft copy or incorporate which draft?

 

Aijun Wang

China Telecom





On Sep 1, 2023, at 20:05, Acee Lindem mailto:acee.i...@gmail.com> > wrote:

Hi Aijun, 





On Aug 31, 2023, at 23:36, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Hi，Acee:

 

Please read  

 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7
 before making misguide assertions:

 

“The advertisement of PUAM message should only last one configurable period to 
allow the services that run on the failure prefixes are switchovered.”

 

 

I guess I haven’t kept up with all the elements of the draft under adoption 
that you continue to incorporate into your draft. This has been a continuing 
theme since initial discussed of the application signaling use case. While I 
have no interest in improving your draft, making the LSP/LSA short-lived 
conflicts with the other scenarios your draft purports to address. 

 

Acee

 





 

Best Regards

 

Aijun Wang

China Telecom

 

发件人:   lsr-boun...@ietf.org [ 
 mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年9月1日 0:50
收件人: Robert Raszuk <  rob...@raszuk.net>
抄送: Les Ginsberg (ginsberg) <  
ginsberg=40cisco@dmarc.ietf.org>; Huzhibo < 
 
huzhibo=40huawei@dmarc.ietf.org>; Peter Psenak <  
ppse...@cisco.com>; linchangwang <  
linchangwang.04...@h3c.com>; lsr <  lsr@ietf.org>
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 

[Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi，Acee:

 

Please read 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7
 before making misguide assertions:

 

“The advertisement of PUAM message should only last one configurable period to 
allow the services that run on the failure prefixes are switchovered.”

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年9月1日 0:50
收件人: Robert Raszuk 
抄送: Les Ginsberg (ginsberg) ; Huzhibo 
; Peter Psenak ; 
linchangwang ; lsr 
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04

 

 





On Aug 31, 2023, at 12:32, Robert Raszuk mailto:rob...@raszuk.net> > wrote:

 

Hi Acee,

 

In any case, one will need to update the signaling routers and the routers 
acting on the signal. 

 

I guess this is clear to all. 

 

Additionally, your request for the adoption was that the draft have a stronger 
statement about the mechanism being used for solely for signaling for 
applications (e.g., BGP PIC).

 

As to the applicability my comment was that either draft should state in strong 
normative language that this is applicable only to applications which data 
plane uses encapsulation to the next hop. 

 

Said this draft-wang introduces the additional signalling, sort of trying to 
assure that all nodes in an area understand the new messages - but I am not 
sure if even advertising PUAM capability means that it will be actually used 
for all destinations ? 

 

No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral 
signal which the WG agreed was a valid use case, in the other draft, the LSAs 
are long-lived and are also may be used for other purposed than signaling 
(e.g., reread both sections 4 and 6 of draft-wang-lsr…). This draft starting 
with a whole different use case but selectively added mechanisms from 
ppsenak-lsr… 

 

I seem to recall you were a strong proponent of limiting the scope. 

 





 

By responding to this Email inline, some may believe you support the assertion 
that we should start the adoption of both drafts. Please be clarify this.

 

Well the way I see this is that adoption call is a bit more formal opportunity 
for WG members to express their opinion on any document. But maybe LSR (for 
good reasons) have different internal rules to decide which document should be 
subject to WG adoption and does sort of pre-filtering. 

 

If adoption call proves document has negative comments or lacks cross vendor 
support it simply does not get adopted. 

 

Maybe I am just spoiled looking at how IDR WG process works :-) 

 

You replied to an Email inline suggesting adoption of both drafts. That is what 
I think could have been misconstrued - especially by those who didn’t follow 
the discussion until now who think you are agreeing with this recommendation.  

 





 

As for your other comment that this could be accomplished with BGP or an 
out-of-bound mechanism, that is true but that could be true of many problem. 
However, the solution under adoption has running code and wide vendor support.

 

 Right ... As I wrote to Peter - perhaps this is just a pragmatic approach and 
flooding is what link state uses so be it. 

 

As you know I did try in the past to propose BGP Aggregate withdraw but then 
feedback of the community was that PEs do not go down that often to justify the 
extension. 

 

Hmm… We seem to have broad support for the LSR application signaling use case. 

 

Thanks,

Acee

 





 

Best,

Robert

 

 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Xuguoqi]

Object its adoption.

This document does not solves area/domain partition, but this is a very common 
scenario. 
From the perspective of comprehensiveness and maturity, I think 
https://datatracker.ietf.org/doc/ Draft-wang-lsr-prefix-unreachable-annoucement 
is a better choice.

Thanks,
Guoqi Xu

-邮件原件-
发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年8月24日 04:07
收件人: lsr 
抄送: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023. 

Thanks,
Acee
___
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] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Aijun Wang]

Hi, Acee:

Please read carefully the description in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-00#section-3:

"In another situation, assume the BGP session is built between Node S2
   and T2, via Ps2 and Pt2 respectively.  If Node S2 within area 1
   become unreachable, the unreachable information can't be advertised
   to Node T2 because the summary behaviour on border router R1/R3.  The
   BGP session between S1 and T2 will be kept until the BGP keepalive
   timeout or other detection mechanism takes effect.  During this
   period, the BGP traffic to Node S2 will be in black hole."

Considering the usage of "infinite metric", version 00 of the 
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-00
 took the implicit signaling approach, it wants to redefine the meaning of 
"infinite metric".  Only after the intense discussions, it switched to the 
explicit signaling approach(version 02, March 2023), which is the direction 
that 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ 
took from the beginning(version 00, October, 2019).

>From the above foundation information, I would like to hear why you can't 
>admit that draft 
>https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> is the first document that provide the problem and the explicit signaling 
>mechanism. 

Best Regards

Aijun Wang
China Telecom


-邮件原件-
发件人: Acee Lindem [mailto:acee.i...@gmail.com] 
发送时间: 2023年8月24日 23:46
收件人: Aijun Wang 
抄送: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

Speaking as WG member: 

> On Aug 24, 2023, at 04:59, Aijun Wang  wrote:
> 
> Object its adoption.
> 
> The reasons are the followings:
> 1) It is not the initial draft to describe the problem and provide the 
> solution. 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> 2) The problem and the explicit signaling mechanism is firstly provided by in 
> its 00 version(October,2019), far earlier than the current proposal and its 
> 00 version(March, 2022).

Let me help you refresh your memory - the -00 version of this draft solved a 
completely different problem. The unreachability signaling to other 
applications (e.g., BGP PIC) was only added after publication of the draft 
under adoption. Over revisions, other aspects of the draft under adoption were 
also appropriated (e.g., using infinite metrics). So, your claims of being 
“first" are unfounded. Let’s stick to the technical differences between the 
drafts. 

Thanks,
Acee



> 3) Even after the proposed draft adopt the explicit signaling mechanism, it 
> still lacks other mechanisms that can cover more prefixes unreachable 
> scenarios, as stated in the 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> 
> The LSR WG should consider to adopt the more comprehensive and simple 
> solution, not the partial and complex design. 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> -邮件原件-
> 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
> 发送时间: 2023年8月24日 4:07
> 收件人: lsr 
> 抄送: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> 主题: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
> draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee
> ___
> 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] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Aijun Wang]

Object its adoption.

The reasons are the followings:
1) It is not the initial draft to describe the problem and provide the solution.
2) The problem and the explicit signaling mechanism is firstly provided by 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ 
in its 00 version(October,2019), far earlier than the current proposal and its 
00 version(March, 2022).
3) Even after the proposed draft adopt the explicit signaling mechanism, it 
still lacks other mechanisms that can cover more prefixes unreachable 
scenarios, as stated in the 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/

The LSR WG should consider to adopt the more comprehensive and simple solution, 
not the partial and complex design. 

Best Regards

Aijun Wang
China Telecom


-邮件原件-
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年8月24日 4:07
收件人: lsr 
抄送: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023. 

Thanks,
Acee
___
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