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

[Aijun Wang]

Hi, John:

Thanks for your reply.
The key concerns for the issue is that although 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement 
has several advantages, it hasn't been given the adoption call until now. This 
is unfair and also our main appeal reason.

Considering there are two different approaches to solve some overlapping 
scenarios, I think we can consider to adopt both of them as WG documents, 
similar with actions of other WGs.
We can let the industry to select the final solution to implement and deploy 
within their networks.

We have enough energies to accomplish the final implementation and deployment.

Some detail responses are inline below.


Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 John 
Scudder
发送时间: 2023年11月1日 6:02
收件人: Aijun Wang 
抄送: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable 
Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

Hi Aijun,

I apologize for the length of time it’s taken me to respond to your request. 

Having now taken the time to study the question properly, including a review of 
both drafts in question, the WG adoption call, and the subsequent email, here’s 
my take.

In large part, your position appears to be based on historical precedence — 
your draft was published first. (This is your “follower solution… initiator” in 
the email I’m responding to, as well as the first three “which draft is the 
first” points in your follow-up.) This is true of course. Furthermore, although 
our formal process does not take into account such questions as “who came 
first?” I think it would be safe for me to say that people generally do try to 
do not just what’s required, but what’s right, in terms of acknowledging prior 
work. For this reason, I was a little surprised to see no acknowledgment of the 
contributions of your draft in draft-ppsenak. But I think such an 
acknowledgment — which is a norm, not a requirement — is the most you can 
expect for having published the first draft that covers the same general 
subject area as draft-ppsenak. This might also be a good time to remind you 
that draft-wang-lsr-prefix-unreachable-annoucement-00 includes the statement,

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

I encourage you to review BCP 78 if you haven’t recently.
【WAJ】In contrast, we include the above statement from the version 00: 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-00,
 and also acknowledge the comments from Peter Psenak, Les Ginsberg, Bruno 
Decraene, Acee Lindem, Shraddha Hegde, Robert Raszuk, Tony Li, Jeff Tantsura 
and Tony Przygienda for their suggestions and comments on draft-wang.

In short, I’m not persuaded by the first-to-publish argument.
【WAJ】We are not advocating the fist-to-publish argument, but the first should 
be considered first for adoption call, or else, there must be reasonable 
explanations for not doing so.

The other major point made by you, and others advocating for the consideration 
of draft-wang as the WG solution and against draft-ppsenak, is that draft-wang 
is said to cover more cases. (This is “cover more scenarios” in your email, as 
well as point five, “cover more scenarios” in your follow-up.) There was some 
spirited debate about whether the draft does so successfully, or not, but I 
don’t want to take a position on that in this email. Rather, what I observe is 
that since these points were made clearly, and repeatedly, in the WG adoption 
email thread as well as at other times previously, it can’t be argued that the 
WG didn’t know that draft-wang claims to address (for example) area partition, 
and that draft-ppsenak explicitly doesn’t. So, this suggests those who 
supported the adoption of draft-ppsenak either implicitly, or explicitly, 
believed that the additional use cases draft-wang claims to address are not 
important. At least, not important to address in this draft, at this time, as 
part of this adopted WG work.
【WAJ】Prefix unreachable announcement is one general mechanism, the solution 
shouldn't be limited only on some narrow scopes. For standardization work, we 
should look further.

In your follow-up, you also proposed that “which explicit signaling mechanism 
is simpler” should be a criterion (point four). In my experience, this kind of 
question seldom leads to a useful outcome since it’s so subjective. I will say 
however that many of the people who responded to the WG adoption call made it 
clear they had such considerations in mind, so I think there is good reason to 
think the WG has taken this question into account.
【WAJ】The adoption call is issued only for one approach, not both of them, then 
how can we get the above conclusions?

I also want to speak to the questions of whether the WG 

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

[Aijun Wang]

Hi, John:

What’s your responses to this issue and my proposal then?

We need your guidances.

Aijun Wang
China Telecom

> On Sep 20, 2023, at 17:22, Aijun Wang  wrote:
> 
> Hi, Acee, John:
> 
> My proposal to solve the issue is that we can discuss the merge possibility 
> for the contents and author list of WG document at the IETF 118 on-site 
> meeting.
> I think you (also LSR experts within the list) can't deny draft-ppsenk was 
> inspired by our draft. 
> It's unfair to ignore the adoption call of 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,
>  
> 
> Detail replies are inline below. 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -邮件原件-
> 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
> 发送时间: 2023年9月16日 1:16
> 收件人: Aijun Wang 
> 抄送: John Scudder ; Christian Hopps 
> ; lsr ; 
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; tom petch 
> 
> 主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable 
> Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
> 
> Aijun, John, 
> 
> Technical comments as WG member: 
> 
> See inline. 
> 
>> On Sep 15, 2023, at 3:08 AM, Aijun Wang  wrote:
>> 
>> Hi,John:
>> 
>> Thanks in advance for your review for the discussion within the mail list.
>> 
>> Normally, the WG adoption call decisions will be coordinated between the 
>> Chairs. That’s the reason that I sort the judgement directly from the AD.
>> 
>> If the previous results represents only Acee’s preference, we would like to 
>> ask Chris to review also all the discussions and expect Chris to solve my 
>> concerns that Acee didn’t convince me. 
>> 
>> The IETF community should respect the initiative idea and adoption decision 
>> should be made based on the facts.
>> 
>> Hi, Chris:
>> 
>> I have asked Acee the following questions 
>> (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/ )and 
>> would like to hear your feedback:
>>> 
>>> 
>>> 
>>> 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? 
> 
> Given that the WG agreed to solve a specific use case, this is irrelevant. 
> [WAJ] The specific use case is also first provided by 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> 
>>> 2) Which draft is the first to propose explicit signaling for 
>>> unreachable information?
> 
> Since the mechanism in your draft use an assumption about the value of 
> prefix-originator, one could argue that it is not strictly explicit. 
> [WAJ] The meaning of newly defined special value of prefix-originator is 
> similar as the meaning of the newly defined flag. 
> 
> However, the first to provide backward-compatible notification focused on the 
> short-lived notification use case was the WG document. 
> [WAJ] I think you have noticed that there was one big conversion from the 
> first version of draft-ppsenk(implicit signaling only) to its latest 
> version(including explicit signaling also). The reason for the conversion is 
> that we insisted that the explicit signaling was the direction.
> 
>>> 3) Which draft is the first to propose short lived notification?
> 
> I believe Robert Raszuk was the first to bring up the use case on the LSR 
> list - well before it was included in any draft.  
> [WAJ] Would you or Robert Raszuk like to provide the link within the LSR list 
> to prove the above imagination? 
> 
>>> 4) Which explicit signaling mechanism is simpler?
> 
> The draft which the WG rallied behind is much cleaner and based on the WG 
> request for explicit unreachable flags. As I mentioned before, it is 
> backward-compatible. Your document also requires a capabilities advertisement 
> and different behavior depending on whether or not all routers in the area 
> support the mechanism (section 5). The WG document is clearly simpler. 
> [WAJ]There is already field to carry such information, it is redundancy to 
> define the flag again. And, the most important thing is that using the 
> existing field can provide the uniform explicit signaling methods for all the 
> IGP protocols, we needn't find different places to set and parse the flags in 
> different protocol. Which is simpler?
> The reason that we keep capabilities advertisement, as I explained in 
> https://mailarchive.ietf.org/arch/msg/lsr/E6Pg6kDppFfrPWJ0h03XivUHB48/ in 
> detail, is that we want to fade out the usage of LSInfinity in future. We 
> should keep and put forward the deployment of such mechanism in simple format 
> or direction, don't make the network operation more complex.
> 
>>> 5) Which draft provides more mechanisms to cover more scenarios?
> 
> While you purport to support multiple use cases, they conflict with one 
> another. For example, the use cases which require a change in OSPF 
> advertisement by the other ABR(s) would require knowledge as 

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

[Aijun Wang]

Hi, Tom:

My appeal is that it's unfair to ignore the draft that was put forward THREE 
years earlier than the follower, and we devote intense discussions for this 
topic along the process, but there is no adoption call. 


Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 tom petch
发送时间: 2023年9月15日 18:41
收件人: Aijun Wang ; John Scudder 
; cho...@chopps.org
抄送: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable 
Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

From: Aijun Wang 
Sent: 15 September 2023 08:08

Hi,John:

Thanks in advance for your review for the discussion within the mail list.

Normally, the WG adoption call decisions will be coordinated between the 
Chairs. That’s the reason that I sort the judgement directly from the AD.

If the previous results represents only Acee’s preference, we would like to ask 
Chris to review also all the discussions and expect Chris to solve my concerns 
that Acee didn’t convince me.

The IETF community should respect the initiative idea and adoption decision 
should be made based on the facts.

Aijun
The IETF community works on 'rough consensus and running code' to a greater or 
lesser extent.  The descriptions of our processes do not give hard and fast 
rules about what constitutes consensus and that flexibility is one of the 
strengths of the IETF.  Consensus is judged, by WG Chairs, AD, IESG, IAB, based 
on what the mailing lists contain.  The judgement can be  appealed.  The result 
can be one I-D going forward or two or none.  Here we currently have consensus 
declared for one I-D to go forward.

I hear you protest and see that as an implicit appeal but I am unclear what you 
are appealing. The appeal could be that consensus does not reflect what  
appeared on the list, that the consensus call was not properly made, that there 
should have been additional consensus calls and so on. 

You list facts and that is fine but they are only input to my and others' 
judgement which we then express in response to a consensus call.  The facts may 
persuade some, they may not persuade others but it is the summation of views 
expressed on the list  that determines the consensus, not facts.

Tom Petch

Hi, Chris:

I have asked Acee the following questions 
(https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/
 )and would like to hear your feedback:

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.

John can also refer the above questions when reviewing the past discussions 
within the list.

Aijun Wang
China Telecom

On Sep 15, 2023, at 04:02, John Scudder  
wrote:

Tom is right of course, and thank you for pointing it out. (The specific 
section in RFC 2026 to look at is 6.5.1.)

In the meantime, I’ll review the mailing list discussion. However, the most 
desirable outcome would be to settle things at the WG level without further 
escalation.

—John

On Sep 14, 2023, at 12:25 PM, tom petch  wrote:

From: Lsr  on behalf of Aijun Wang 

Sent: 14 September 2023 11:38

Hi, Acee:

I admire your efforts for the LSR WG, but for the adoption call of this draft, 
you have not convinced me, although I gave you large amount of solid facts.
Then, it's time to let our AD to step in, to make the non-biased judgement, 
based on our discussions along the adoption call.



I think that what you have in mind is an appeal, as per RFC2026.

The first stage therein is to involve the Chairs, and while Acee is one, he is 
not the only one.

Have you involved the other Chair, on or off list? That would seem to me to be 
next step.

Tom Petch


We request the WG document be based on the 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5KWnyE3KA$
 , because it is the first document to initiate the use case, provide the 
explicit signaling mechanism, and cover more scenarios.

It’s unreasonable to adopt the follower solution and ignore the initiator. We 
started and lead the discussions THREE years earlier than the current proposal.

Aijun Wang
China Telecom

On Sep 8, 2023, at 23:16, Acee Lindem  wrote:

The WG adoption call has completed and there is more than sufficient support 
for adoption.
What’s more, vendors are 

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

[Aijun Wang]

Hi, Acee, John:

My proposal to solve the issue is that we can discuss the merge possibility for 
the contents and author list of WG document at the IETF 118 on-site meeting.
I think you (also LSR experts within the list) can't deny draft-ppsenk was 
inspired by our draft. 
It's unfair to ignore the adoption call of 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,
 

Detail replies are inline below. 

Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年9月16日 1:16
收件人: Aijun Wang 
抄送: John Scudder ; Christian Hopps 
; lsr ; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; tom petch 

主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable 
Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

Aijun, John, 

Technical comments as WG member: 

See inline. 

> On Sep 15, 2023, at 3:08 AM, Aijun Wang  wrote:
> 
> Hi,John:
> 
> Thanks in advance for your review for the discussion within the mail list.
> 
> Normally, the WG adoption call decisions will be coordinated between the 
> Chairs. That’s the reason that I sort the judgement directly from the AD.
> 
> If the previous results represents only Acee’s preference, we would like to 
> ask Chris to review also all the discussions and expect Chris to solve my 
> concerns that Acee didn’t convince me. 
> 
> The IETF community should respect the initiative idea and adoption decision 
> should be made based on the facts.
> 
> Hi, Chris:
> 
> I have asked Acee the following questions 
> (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/ )and 
> would like to hear your feedback:
>> 
>> 
>> 
>> 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? 

Given that the WG agreed to solve a specific use case, this is irrelevant. 
[WAJ] The specific use case is also first provided by 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/

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

Since the mechanism in your draft use an assumption about the value of 
prefix-originator, one could argue that it is not strictly explicit. 
[WAJ] The meaning of newly defined special value of prefix-originator is 
similar as the meaning of the newly defined flag. 

However, the first to provide backward-compatible notification focused on the 
short-lived notification use case was the WG document. 
[WAJ] I think you have noticed that there was one big conversion from the first 
version of draft-ppsenk(implicit signaling only) to its latest 
version(including explicit signaling also). The reason for the conversion is 
that we insisted that the explicit signaling was the direction.

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

I believe Robert Raszuk was the first to bring up the use case on the LSR list 
- well before it was included in any draft.  
[WAJ] Would you or Robert Raszuk like to provide the link within the LSR list 
to prove the above imagination? 

>> 4) Which explicit signaling mechanism is simpler?

The draft which the WG rallied behind is much cleaner and based on the WG 
request for explicit unreachable flags. As I mentioned before, it is 
backward-compatible. Your document also requires a capabilities advertisement 
and different behavior depending on whether or not all routers in the area 
support the mechanism (section 5). The WG document is clearly simpler. 
[WAJ]There is already field to carry such information, it is redundancy to 
define the flag again. And, the most important thing is that using the existing 
field can provide the uniform explicit signaling methods for all the IGP 
protocols, we needn't find different places to set and parse the flags in 
different protocol. Which is simpler?
The reason that we keep capabilities advertisement, as I explained in 
https://mailarchive.ietf.org/arch/msg/lsr/E6Pg6kDppFfrPWJ0h03XivUHB48/ in 
detail, is that we want to fade out the usage of LSInfinity in future. We 
should keep and put forward the deployment of such mechanism in simple format 
or direction, don't make the network operation more complex.

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

While you purport to support multiple use cases, they conflict with one 
another. For example, the use cases which require a change in OSPF 
advertisement by the other ABR(s) would require knowledge as long as the prefix 
is unreachable. You also have section 7 which is relevant to persistent 
notification and not the short-lived notification agreed upon by the WG. 
[WAJ] It is not enough to consider only the sender mechanism and doesn't 
consider its usage in more complex situations. Even in partition scenario, the 
advertisement of PUAM message need not last