(“Extended IS Reachability” and
“Extended IP Reachability”), and leaves many unsolved, or in chaos
states/possibilities.
I am wondering how the WG chairs can put forward this document in current
content.
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org
Hi, Tony:The aim of the standard is to improve and assure the interoperability, and correct the vendor that doesn’t comply it.If the proposed document can’t achieve such goal, what’s the gain to forward the document to RFC?Aijun WangChina TelecomOn Sep 13, 2024, at 14:13, Tony Li wrote:Hi Jimmy,I
ion for
every IS-IS (Possible Big) TLV code point, and also the necessity of per-TLV
capability announcement.
Any comments are welcome.
Best Regards
Aijun Wang
On behalf of the co-authors
-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
发送时间: 2024年9月11日 1
-TLV problem.
I can't see other values except the key definition of TLV 22 and TLV 135 from
the current version.
Following such direction, the operator will be busy to coordinate the vendors,
the deployment for the opened Pandora's box
Best Regards
Aijun Wang
China Tele
mail offended the WG chairs, i apologize for my
negligence. But the technical appeal will be undergone if there is no more
change or updates for the WGLC document.
Aijun Wang
China Telecom
> On Sep 4, 2024, at 17:51, Gunter van de Velde (Nokia)
> wrote:
>
> Hi Aijun,
>
>
Hi, Chris:
Please give the proof where is the WG's consensus? We all can see and retrieve
all the responses from its WGLC process publicly.
Please note: The chairs' preference doesn’t represent the WG's consensus.
Best Regards
Aijun Wang
China Telecom
-邮件原件-
发件人: f
Hi, Les:If the following key points can’t be solved, what the meaning to wrap around, around and around… …the wording games?1) If there is no key definition for each MP-TLV capable codepoint, how to fragment and concatenate the sliced MP-TLV?2) If there is no indication for the capabilities of whic
es lead no interoperability?
Best Regards
Aijun Wang
China Telecom
发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2024年8月9日 15:19
收件人: Aijun Wang ; bruno.decra...@orange.com;
'Yingzhen Qu' ; 'lsr' ; 'lsr-chairs'
主题: RE: [Lsr] Re: WG Last Cal
s will be emerged for
>the undefined “key” field part of the one code point.
Anyone understands the process of segment/concatenate process should be aware
the exact “key” field, why do we argue it constantly for this obvious
requirements?
Best Regards
Aijun Wang
Chin
Hi, Chris:
Aijun Wang
China Telecom
> On Aug 8, 2024, at 20:53, Christian Hopps wrote:
>
> [As WG member]
>
> I'm neutral on whether the RFC should try and identify what the specific key
> is for all the existing TLVs; however, I think the current draft does define
with the large packet within the network.
Then, without definition of such “key” information within the proposed
document, we can’t say we have solved the aimed problem.
On the contrary, it introduces more chaos within the network.
Best Regards
Aijun Wang
China Telecom
发件人
please
point it out clearly in which part of the document.
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les
Ginsberg (ginsberg)
发送时间: 2024年8月7日 10:57
收件人: Aijun Wang ; bruno.decra...@orange.com; 'Ketan
Talau
Hi, Les:
If there is no key, how “focused on the conceptual use of the key in support of
multi-TLV.”?
And, how do you distinguish the situation that you described as “stale/current”
replacement and both “current”? Will it arise another interoperable problem?
Best Regards
Aijun
t we need other
creative solution to solve such issue in one extensible manner.
Best Regards
Aijun Wang
China Telecom
-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Tony
Li
发送时间: 2024年8月5日 12:40
收件人: Aijun Wang
抄送: lsr@ietf.org
主题: [Lsr] Re: 答复: 【Wh
give to clue to the vendors to implement it /s give no clue to the vendors to
implement it.
-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
Aijun Wang
发送时间: 2024年8月5日 9:56
收件人: lsr@ietf.org
主题: [Lsr] 【What's the reason to move forward this docume
vendors to
implement it.
Look forward the WG, or IESG abandon it.
Best Regards
Aijun Wang
China Telecom
邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
internet-dra...@ietf.org
发送时间: 2024年8月3日 9:08
收件人: i-d-annou...@ietf.org
抄送: lsr@ietf.org
主题: [Lsr]
Such protocol extension is more clear to solve the mentioned race condition,
and is more traceable.
Best Regards
Aijun Wang
China Telecom
-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Tony
Li
发送时间: 2024年7月17日 11:39
收件人: Aijun Wang
抄送: Christian Hopps ;
the neighbors around the restarting router
to pause the advertisement of updated LSAs that related to the interfaces
connects to the restarting router, which is one typical " cache synchronization
problems " that you mentioned.
Why don't clear the stale LSPs in advance by the p
and still is. Let's not go there-- tony On Mon, Jul 15, 2024 at 1:26 PM Aijun Wang <wangai...@tsinghua.org.cn> wrote:Hi, Acee:If you think all of the solutions are not perfect, can we find other solutions, such as assigning/selecting in advance one proxy router for the possible disrupt
guing for a more complete solution. Les
From: Tony Przygienda
Sent: Friday, July 12, 2024 11:23 AM
To: Acee Lindem
Cc: Les Ginsberg (ginsberg) ; Liyan Gong ; Aijun Wang ; Peter Psenak (ppsenak) ; Yingzhen Qu ; lsr ; lsr-chairs ;
shraddha
Subject: Re: [Lsr] About Premature aging of LSA and
direct connected routers?And, your proposal needs the changes of the state machines of the current OSPF implementation, it is unconvinced that you call them “simpler”.Aijun WangChina TelecomOn Jul 11, 2024, at 23:28, Acee Lindem wrote:As WG member: On Jul 11, 2024, at 05:29, Aijun Wang wrote:And
And, there is also another draft aims to solve the similar problem
https://datatracker.ietf.org/doc/html/draft-cheng-lsr-ospf-adjacency-suppress-02,
which it declares similar with the solution in IS-IS. Why not take this
approach?
Best Regards
Aijun Wang
China Telecom
发件人
...@ietf.org] 代表 Acee
Lindem
发送时间: 2024年7月10日 22:14
收件人: Aijun Wang
抄送: Peter Psenak ; Yingzhen Qu ;
lsr ; lsr-chairs ; tony Przygienda
; shraddha
主题: [Lsr] Re: About Premature aging of LSA and Purge LSA
Yes - but the whole discussion of adjacency suppression and database
synchronization is based on
For the unplanned restart, shouldn’t the responsibility of the directed connect
neighbors to send out such LSAs for the purge of obsolete LSA?
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee
Lindem
发送时间: 2024年7
router restart, it needs only send out the Purge
LSA(when LSA sequence number is not to wrap) or premature aging of its
LSA.(when sequence number is to wrap)
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
代表 Acee Lindem
发送时间
for each key field definition of the MP-TLV later?
In summarize, there is no obvious points that can support to forward this
document that can lead to more chaos in network than not deploying it at all.
Best Regards
Aijun Wang
China Telecom
发件人: Les Ginsberg (ginsberg
ned question, will only lead to more chaos within the network.
We should not forward this document at the current stage.
More works should be done to solve the issue.
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf
draft to solve these limitations.
Or else, we expect to discuss them further and more deeper in the coming times.
As operators, we expect to find one more attractive solution.
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori
e the same services. The difference is that the path
attributes(internal links and stub link) to them.
Wish the above explanations can address your concerns.
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les
Gin
the most onerous one?Aijun WangChina TelecomOn Jan 18, 2024, at 17:29, Aijun Wang wrote:Hi, Les: 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)发送时间: 2024年1月18日 0:16收件人: Aijun Wang 抄送: Christian Hopps ; Huzhibo ; Acee Lindem ; Yingzhen Qu ; lsr
Hi, Les:
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les
Ginsberg (ginsberg)
发送时间: 2024年1月18日 0:16
收件人: Aijun Wang
抄送: Christian Hopps ; Huzhibo ; Acee
Lindem ; Yingzhen Qu ;
lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
, the proposed solution is more efficient that
the existing solution. The operator can omit many onerous work.
And, the proposed solution is not only for topology recovery, it can also cover
other use cases(for example A.2/A.3)
Best Regards
Aijun Wang
China Telecom
发件人
inline.
From: Aijun Wang
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps' ; 'Huzhibo'
Cc: 'Acee Lindem' ; 'Yingzhen Qu' ; lsr@ietf.org
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attribut
Hi, Les:
-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: Christian Hopps ; Huzhibo
抄送: Acee Lindem ; Yingzhen Qu
; lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/
Hi, Acee:
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee
Lindem
发送时间: 2024年1月16日 6:44
收件人: Aijun Wang
抄送: Christian Hopps ; Liyan Gong
; Yingzhen Qu ; lsr
; lsr-chairs
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024
- 01
configuration simplification arguments.
Aijun Wang
China Telecom
> On Jan 15, 2024, at 20:19, Christian Hopps wrote:
>
>
>
>> On Jan 15, 2024, at 06:27, Aijun Wang wrote:
>>
>> Hi, Chris：
>>
>> There are significant changes from the last adoption c
/RFC5392), but how many operators have deployed them in the
network? Are anyone considering the reason that hinders their deployments?
Aijun Wang
China Telecom
> On Jan 15, 2024, at 17:35, Christian Hopps wrote:
>
> Liyan Gong writes:
>
>> Hi WG,
>>
>&
.
Best Regards
Aijun Wang
China Telecom
-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
Christian Hopps
发送时间: 2024年1月10日 18:17
收件人: Huzhibo
抄送: Acee Lindem ; Yingzhen Qu ;
lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
also other cases(for example, A.2, which is not the inter-AS
scenarios) that can utilize these attributes of the stub links.
Best Regards
Aijun Wang
China Telecom
-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
代表 Peter Psenak
发送时间: 2024年1月10日 1:08
收件人
Hi, Les:
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les
Ginsberg (ginsberg)
发送时间: 2024年1月9日 5:03
收件人: Yingzhen Qu ; lsr ; lsr-chairs
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/05/2024 - 01/19/2024)
I oppose WG adoption.
T
Hi, Acee:
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee
Lindem
发送时间: 2024年1月9日 3:03
收件人: Yingzhen Qu
抄送: lsr
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/05/2024 - 01/19/2024)
Speaking as WG member:
I don’t support adopti
, A.3.
Wish to get to your support to forward and refine it.
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
Yingzhen Qu
发送时间: 2024年1月6日 8:23
收件人: lsr ; lsr-chairs
主题: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link
and receiving of the multi-part of this TLV.
Or else, we should think other solution to solve this issue.
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Tony
Li
发送时间: 2023年11月29日 0:49
收件人: Aijun Wang
抄送: Yingzhen Qu
interoperability?
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
Aijun Wang
发送时间: 2023年11月24日 16:11
收件人: 'Yingzhen Qu' ;
draft-pkaneria-lsr-multi-...@ietf.org; 'lsr'
主题: [Lsr] 答复: WG Adoption Call - draf
sues or not, for the scenario, for
the solution, for the encoding etc.
Best Regards
Aijun Wang
China Telecom
-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee
Lindem
发送时间: 2023年11月16日 3:56
收件人: Aijun Wang
抄送: Christian Hopps ; Yingzhen
on the needs of the deployment
scenarios in which it is used”-Will there be many interoperability issues
arises then? And also varies loop accidents within the network when all of
vendors declare they support “MP-TLV” but not all of the relevant TLVs?
Best Regards
Aijun Wang
China
we are even arguing about this :-(
On Wed, Nov 15, 2023 at 1:50 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:
Hi, Ketan:
The logic is that why we can set router-id equal to 0.0.0.0 to indicate some
information in some standards, but we can’t set prefix originator infor
ive of the arguments/logic provided.Let us agree to disagree.At least I've concluded that it is no more fruitful for me to try to convince you. C'est la vie ...Thanks,KetanOn Tue, Nov 7, 2023 at 11:08 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote:Hi, Ketan:There are many examples
still following this thread).On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote:Hi, Ketan and Les:There are two sub-TLVs to indicate the source information of the prefix within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router Address”What’s you re
(ginsberg)
Cc: John Drake ; Peter Psenak (ppsenak) ; Aijun Wang ; lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
Hi Les,
I disagree with your reading of RFC9084 (OSPF Prefix Originator).
Sec 1
This document proposes extensions to the
Hi, Peter:
Let’s focus on the technical analysis/comparison for the mentioned issues, and
don’t repeat the subjective comments that without any solid analysis.
Detail replies inline below.
Aijun Wang
China Telecom
> On Nov 6, 2023, at 14:53, Peter Psenak wrote:
>
> Aijun,
>
carefully before evaluating and
adopted any proposal.
If the above issues can’t be solved, we request the WG to adopt also the
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which
cover and solve all of the above issues.
Aijun Wang
China
rgies 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 ;
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
> fo
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
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
, I’ll review the mailing list discussion. However, the most desirable outcome would be to settle things at the WG level without further escalation.—JohnOn Sep 14, 2023, at 12:25 PM, tom petch wrote:From: Lsr on behalf of Aijun Wang Sent: 14 September 2023 11:38Hi, Acee:I admire your efforts for the
ution 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 adoptio
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
收件人
erged 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 submitt
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
-ppsenak(March 25,2022)Then, which draft copy or incorporate which draft?Aijun WangChina TelecomOn Sep 1, 2023, at 20:05, Acee Lindem wrote:Hi Aijun, On Aug 31, 2023, at 23:36, Aijun Wang wrote:Hi，Acee: Please read https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
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 &quo
Hi, Les:
Please do not mislead the experts within the LSR.
Detail replies are inline below.
Best Regards
Aijun Wang
China Telecom
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Les Ginsberg
(ginsberg)
发送时间: 2023年8月31日 22:49
收件人: Huzhibo ; Peter Psenak (ppsenak
://mailarchive.ietf.org/arch/msg/lsr/r-qLlA2JW-JOLVf_LBlEXwE01jE/
Best Regards
Aijun Wang
China Telecom
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Les Ginsberg
(ginsberg)
发送时间: 2023年8月31日 10:57
收件人: Huzhibo ; Peter Psenak (ppsenak)
; linchangwang ; Acee Lindem
; lsr
抄
diffs across the 13 versions illustrate the history and evolution.I am unable to explain in ways other than what has been already done in the past threads.Thanks,KetanOn Tue, Aug 29, 2023 at 1:33 PM Aijun Wang <wangai...@tsinghua.org.cn> wrote:Hi, Ketan:Which part in https://datatracker.
Hi, Ketan:Which part in https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ is not workable?I want to remind you again that it is the above draft initiates the problem first, insists that the explicit signaling was the direction, covers more scenarios that draft-ppsenak
om 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
Aij
://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
Hi, All Experts:
The main updates of this version is that we put the newly defined "OSPF
Stub-Link TLV" back into the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA for
OSPFv2/v3 respectively.
Your comments are welcome.
We think it is ready for the WG adoption call then.
Best Regards
n the network long time. Exploitable this value is straightforward to be implemented/deployed.Aijun WangChina TelecomOn Mar 27, 2023, at 15:02, Aijun Wang wrote:Hi, Bruno:Let me answer some questions from you based on the current PUA solution. From the inline replies, we think the converged draft shou
Hi, Shraddha:
The PUA/UPA message is mainly for control plane switch over, not for data plane
switch over.
For the planned maintenance, the controller plane switch over should be planned
as well. It doesn’t need IGP to step in.
Aijun Wang
China Telecom
> On Mar 29, 2023, at 00:29, Shrad
The following sentence should be:
> If it is planned, why the overlay service being switched over as scheduled?
If it is planned, why doesn’t the overlay service be switched over as scheduled?
Aijun Wang
China Telecom
> On Mar 28, 2023, at 19:53, Aijun Wang wrote:
>
>
the accident network failures.
Please pay more attentions to other aspects of such mechanism.
Aijun Wang
China Telecom
> On Mar 28, 2023, at 18:51, Peter Psenak
> wrote:
>
> On 28/03/2023 11:41, Aijun Wang wrote:
>> There is already overload bit to accomplish the maintenance p
There is already overload bit to accomplish the maintenance purposes,
Why do you guys repeat such work again?
Aijun Wang
China Telecom
> On Mar 28, 2023, at 18:00, Shraddha Hegde
> wrote:
>
>
> Hi Robert,
>
> > Second, if you say this is needed for BGP free dep
Agree.
The possible scenario for UP flag is not the original intention of our
discussion.
We should abandon it and focus mainly on the other aspects of the solution.
Aijun Wang
China Telecom
> On Mar 27, 2023, at 17:06, Robert Raszuk wrote:
>
>
> Hi,
>
> I woul
Hi, Bruno:Let me answer some questions from you based on the current PUA solution. From the inline replies, we think the converged draft should be based on PUA draft.Aijun WangChina TelecomOn Mar 27, 2023, at 14:00, bruno.decra...@orange.com wrote:
Hi
authors,
Please find below some que
Hi, Les:As I remembered, https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-extended-hierarchy/ will not be forwarded, and the proposed hierarchy within ISIS is not practical.Then, it seems that we can still treat area same as the level 1. It’s the time to reduce the confusion?Aijun WangChina T
What’s the reason to keep area in the description? Is there any flooding activities that based on area?I suggest also remove the mention of area in these descriptions.Aijun WangChina TelecomOn Feb 14, 2023, at 18:16, Chris Parker wrote:Thank you to all who replied for your consideration, and than
Hi, Robert:
> "other than building the normal IP routing table"
There may be different purposes, so advertise the “unreachable within the
summary address” should be signed explicitly.
Aijun Wang
China Telecom
> On Nov 12, 2022, at 11:59, Robert Raszuk wrote
in some sense.
Aijun Wang
China Telecom
> On Nov 10, 2022, at 10:48, Robert Raszuk wrote:
>
>
> Thx Acee ...
>
> Since you mentioned "sparse" and since you highlighted that OSPF is better
> then ISIS for this as it runs over IP I took a risk if not using flood
no more constrained for the network
planning, network operations.
There are already amounts of solutions cannot be deployed widespread in the
network.
Let’s take the explicit signaling approaches.
Aijun Wang
China Telecom
> On Nov 10, 2022, at 10:41, Peter Psenak
> wrote:
>
&g
team.
Aijun Wang
China Telecom
>
>> I wasn't clear on that in the first mail but Bruno clarified
>> that this would still be inside a high-metric prefix reachability TLV.
>> The only difference is that there is a flag/sub-TLV inside that triggers
>> UPA behavior. How
One more information:
The explicit solution,
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
does not require all the nodes be upgraded simultaneously.
Aijun Wang
China Telecom
> On Nov 9, 2022, at 12:06, Peter Psenak
> Using a new Sub-TLV to
he meaning of “LSInfinity”,
no more explanations, no more confusion then.
Aijun Wang
China Telecom
> On Nov 9, 2022, at 12:06, Peter Psenak
> wrote:
>
> Hi David,
>
>> On 09/11/2022 11:44, David Lamparter wrote:
>> Hi Peter, hi all,
>> to iterate on the co
So, the discussion will be back to the origin?
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Peter Psenak
Sent: Wednesday, November 2, 2022 4:20 PM
To: Aijun Wang
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] 【Object the update of LSInfinity usage in RFC8362 】Re
also several folks, include myself, aren’t convinced yet for such
approaches.
Aijun Wang
China Telecom
> On Oct 28, 2022, at 22:34, Peter Psenak
> wrote:
>
> Aijun,
>
> several folks, including myself, has explained to you previously that your
> claims regarding
Object!
I have summarized the reason at
https://mailarchive.ietf.org/arch/msg/lsr/iqcgBvMIPcVxWpfK-AW9MUhpKes/.
Please give the reasonable responses before making any unsound attempts.
Such updates, implementation and deployment will introduce chaos within the
network.
Aijun Wang
China
One correction for the hyper link of the updated draft:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-05
The number 5 is carried return in the second line in previous mail.
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Aijun Wang
Sent: Friday
ger to get rough consensus for the forwarding of this
updated draft.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of
internet-dra...@ietf.org
Sent: Friday, October 21, 2022 11:08 AM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr]
A use the same length of metric fields.
I think we can find other solutions for the proposals that based on the
"LSInfinity", if not, please state them on the list, let's discuss them and
accomplish such aims.
Best Regards
Aijun Wang
China Telecom
-Original Message-
One correction:
“It should be expanded further” should be “it shouldn’t be expanded further”
Aijun Wang
China Telecom
> On Oct 13, 2022, at 18:53, Aijun Wang wrote:
>
> Hi, Acee and Peter:
>
> I think you all misunderstood the intent of his scenario.
> The correct und
usage of LSInfinity defined in RFC2327. It should be
expanded further.
How to apply it in RFC8362 is another issue, as indicated my responses in
another thread.
In summary, again, we should constrain or depreciate the confusion usages of
LSInfinity.
Aijun Wang
China Telecom
> On Oct 13, 2
e of the R-bit [RFC5340] as a
solution to the problem addressed in the text."
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Acee Lindem
(acee)
Sent: Wednesday, October 12, 2022 10:07 PM
To: Aijun Wang
Cc: Peter Psenak (p
eaningthe last
resort of the route to the prefixes.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Huzhibo
Sent: Thursday, October 13, 2022 2:26 PM
To: Peter Psenak ; lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity
Hi LSR:
LS
other attached area as one summary prefix?
Aijun Wang
China Telecom
> On Oct 12, 2022, at 18:22, Acee Lindem (acee)
> wrote:
>
>
>
> On 10/12/22, 2:31 AM, "Lsr on behalf of Aijun Wang" behalf of wangai...@tsinghua.org.cn> wrote:
>
>Hi, Acee:
>
&g
, LSInifinity is just the maximum value of the prefix metric.
The above usage is same as the other value of the metric, then define them or
not is trival-The operator can use any other large enough value to divert
the traffic in your mentioned scenarios.
Best Regards
Aijun Wang
.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Acee Lindem
(acee)
Sent: Tuesday, October 11, 2022 11:20 PM
To: Peter Psenak (ppsenak) ; Aijun Wang
; 'Ketan Talaulikar'
Cc: lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSIn
it is difficult
and complex for the operator to run the network based on such special treatment.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Peter Psenak
Sent: Monday, October 10, 2022 3:56 PM
To: Aijun Wang ; 'Acee Lindem (acee)&
ted advertisements of the same TLV.
Is there any other difficult points to be solved?
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Christian
Hopps
Sent: Sunday, October 9, 2022 8:49 AM
To: Les Ginsberg (ginsberg)
Cc: Christian Hopps ; Tony
1 - 100 of 504 matches
Mail list logo
