this 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
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
Ginsberg
to 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-attributes (01/05/2024 - 01/19/2024)
Hi, Les
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
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
the 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
.
There are 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.
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
, 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
the 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 - draft-pkaneria-lsr-multi
ou have other issues 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
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 within IETF that sp
is 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
(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
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
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
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
>
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
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
, 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
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.
&
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
收件人
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
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
-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
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 &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
e 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
Ch
://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
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 should
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
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
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
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
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
, and 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. However,
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
.
There are 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 regard
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]
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-
From: lsr
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 cor
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
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 (ppsena
gthe 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:
LSInfin
into
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
.
Then, 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 LSInfinity
Hi
, 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)'
; 'Ketan
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
goals.
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Acee Lindem
(acee)
Sent: Saturday, October 8, 2022 4:03 AM
To: Ketan Talaulikar ; Peter Psenak
Cc: lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity
Hi Peter, Ketan,
We’ll do another WG
its original purpose.
Aijun Wang
China Telecom
> On Aug 19, 2022, at 18:27, Huzhibo
> wrote:
>
> Hi Aijun,
>
> Thanks for your detailed review and please check inline below for responses.
>
>
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wan
the new “Locator LSA”.
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Acee Lindem
(acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Exten
the alternative systematic solution will obsolete RFC8919 and RFC8920
together.
The bis draft are just repeating its precedent, and will be replaced also
accordingly, unless it solves the issues that I mentioned.
Aijun Wang
China Telecom
> On Aug 9, 2022, at 21:50, Christian Hopps wrote:
>
&g
. It is necessary to divide/group all the above items
based on application, not just the attributes.
Aijun Wang
China Telecom
> On Aug 9, 2022, at 18:31, Acee Lindem (acee) wrote:
>
> Hi Aijun,
>
> And the BIS changes are more clarifications than changes to the existing RFC
ion of ASLA are still complex, the
deployment of them are challenging.
Is there any real deployment for RFC8919 until now?
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: lsr-boun...@ietf.org On Behalf Of Christian
Hopps
Sent: Monday, August 8, 2022 6:17 PM
To: lsr@ietf.org
ring the normal SPF computation. This allows advertisement of a
prefix for purposes other than building the normal IP routing table.
"
The "purposes" of such prefixes should be indicated explicitly by other
means, as that proposed in the PUA draft.
Best Regards
Aijun Wang
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
Hi, Robert:
I think your proposal are valid.
Option C like deployment can also use such information to select the optimized
inter-AS link to reach the routers in other domain.
The final effect will be like the EPE scenario.
Aijun Wang
China Telecom
> On Jul 29, 2022, at 16:44, Robert Ras
.
Best Regards
Aijun Wang
China Telecom
From: Ketan Talaulikar
Sent: Thursday, July 28, 2022 4:54 PM
To: Aijun Wang
Cc: Les Ginsberg (ginsberg) ; Acee Lindem
(acee) ; lsr
Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
Hi Aijun,
Please check inline below
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 aft
links are used to correct servers,
there is no remote-AS, remote ASBR ID information. But we can distinguish
different stub link via their associated prefixes.
Aijun Wang
China Telecom
> On Jul 28, 2022, at 15:03, Ketan Talaulikar wrote:
>
>
> Hi Aijun,
>
> Similar to Les, I
to
operate.
Aijun Wang
China Telecom
> On Jul 28, 2022, at 14:58, Ketan Talaulikar wrote:
>
>
> Hi Acee,
>
> Thanks for your clarifications and please check inline below for responses as
> co-author of the referenced BGP-LS draft with Aijun.
>
>> On Thu, Jul 28
can elaborate again to you——-“The
prefix sub-TLV is not the link identifier, it is just one kind of link
attributes”. Is it clear enough?
Based on these facts, I think it is unnecessary to response your other baseless
comments.
Aijun Wang
China Telecom
> On Jul 28, 2022, at 12:51,
s(EPE like approach to the connected server),
such information can also be utilized by other internal routers, not only the
controller.
Best Regards
Aijun Wang
China Telecom
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 21:35
收件人: Aiju
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
Hi, Ketan:
Thanks for your comments and suggestions!
Some responses are inline below.
We can update the draft accordingly after we reach consensus on these points.
Best Regards
Aijun Wang
China Telecom.
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Ketan
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?
Anyway, this can be discussed further later after the adoption.
Best Regards
Aijun Wang
China Telecom
发件人: Ketan
ethod.
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
the unreachability of the important component
prefixes to ensure traffic is not black hole sink routed for the
above overlay services.
Then considering only the BFD sessions among PEs are not enough, even we put
aside the BFD sessions overhead on each PE.
Best Regards
Aijun Wang
Then considering both the scalability and possible false negative of BFD based
solution, can we say that the PUA/UPA solution is more preferable?
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Greg Mirsky
Sent: Monday, July 18, 2022 8:39 AM
To: Robert
xperts.
We will try to make some summarizations on the coming IETF meetings.
Please feel free to comments on the updated contents, or the overall solution.
Best Regards
Aijun Wang
China Telecom
-Original Message-
From: internet-dra...@ietf.org
Sent: Monday, July 11, 2022 8:50 AM
To: Aijun W
be configured on the
ABR. Currently, we interest mainly the node’s reachability(that is, the
loopback addresses of the routers).
Aijun Wang
China Telecom
> On Jun 21, 2022, at 20:40, Van De Velde, Gunter (Nokia - BE/Antwerp)
> wrote:
>
>
> wrt partitioned area’s and UPA’s. The
Hi, Anup:
The advantage of PUA over BFD is that the operator needs not deploy o(n^2) BFD
sessions for the services that rely on the IGP reachablity.
Such comparisons have been discussed on the list.
Aijun Wang
China Telecom
> On Jun 18, 2022, at 12:55, Anup MalenaaDu wrote:
>
&g
. These are all
applications of the PUA/UPA messages, and we can add some statements if
necessary on the deployment considerations parts.
Aijun Wang
China Telecom
> On Jun 16, 2022, at 16:10, Van De Velde, Gunter (Nokia - BE/Antwerp)
> wrote:
>
>
> Hi Gyan, Daniel, Peter, Al
explicitly.”
Whether defining a new flag or use the prefix originator information(as adopt
by
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4)
to indicate explicitly the prefix is unreachable can be further discussed.
Aijun Wang
China Telecom
in the standards, as
described in previous section, an advertisement of the inter-area or
external prefix inside OSPF or OSPFv3 LSA that has the age set to
value lower than MaxAge and metic set to LSInfinity can be
interpreted by the receiver as a UPA.
Aijun Wang
China Telecom
> On
assumption.
Aijun Wang
China Telecom
> On Jun 15, 2022, at 19:18, Peter Psenak
> wrote:
>
> Aijun,
>
>> On 15/06/2022 12:12, Aijun Wang wrote:
>> Hi, Peter:
>> If you use LSInfinity as the indicator of the prefixes unreachable, then how
>> about you solve the
1 - 100 of 463 matches
Mail list logo
