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/ <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 <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 <wangai...@tsinghua.org.cn>
*抄送:*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" - 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/ <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 <wangai...@tsinghua.org.cn
<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
<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 <acee.i...@gmail.com
<mailto:acee.i...@gmail.com>> wrote:
Hi Aijun,
On Aug 31, 2023, at 23:36, Aijun Wang
<wangai...@tsinghua.org.cn
<mailto:wangai...@tsinghua.org.cn>> wrote:
Hi，Acee:
Please
readhttps://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7
<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>[mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>]*代表*Acee Lindem
*发送时间:*2023年9月1日0:50
*收件人:*Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk.net>>
*抄送:*Les Ginsberg (ginsberg)
<ginsberg=40cisco....@dmarc.ietf.org
<mailto:ginsberg=40cisco....@dmarc.ietf.org>>; Huzhibo
<huzhibo=40huawei....@dmarc.ietf.org
<mailto:huzhibo=40huawei....@dmarc.ietf.org>>; Peter Psenak
<ppse...@cisco.com <mailto:ppse...@cisco.com>>; linchangwang
<linchangwang.04...@h3c.com
<mailto:linchangwang.04...@h3c.com>>; lsr <lsr@ietf.org
<mailto:lsr@ietf.org>>
*主题:*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
<rob...@raszuk.net <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 <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
