Hi, Robert:
From: Robert Raszuk
Sent: Tuesday, March 29, 2022 3:53 PM
To: Aijun Wang
Cc: Tony Li ; Aijun Wang ; lsr
Subject: Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the
node live?
Aijun,
Your email is written prove that my question the other day which
-unreachable-annoucement-08#section-3.2.
The corresponding solution will be updated later.
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Robert Raszuk
Sent: Wednesday, March 30, 2022 4:58 PM
To: Aijun Wang
Cc: Aijun Wang ; Tony Li
its usage
only for maintenance scenarios as described in RFC8500.
For the encoding, I think the “offset” value and the “O” bit is not necessary,
because the meaningful “Reverse Metric” should be the maximum value of the
metric.
Best Regards
Aijun Wang
China Telecom
From: lsr-boun
Aijun Wang
China Telecom
From: Ketan Talaulikar
Sent: Tuesday, April 19, 2022 6:59 PM
To: Aijun Wang
Cc: Les Ginsberg (ginsberg) ; Acee Lindem
(acee) ; lsr ;
draft-ietf-lsr-ospf-reverse-met...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for
draft-ietf-lsr-ospf-reverse-metric
value is
offset directly(as that in RFC8500), and needn’t introduce the H/O bit to
complex the implementation and deployments.
Best Regards
Aijun Wang
China Telecom
From: Ketan Talaulikar
Sent: Wednesday, April 20, 2022 6:47 PM
To: Aijun Wang
Cc: Les Ginsberg (ginsberg) ; lsr
t your direction.
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Ketan Talaulikar
Sent: Thursday, April 21, 2022 11:00 PM
To: Acee Lindem (acee)
Cc: Les Ginsberg (ginsberg) ; Aijun Wang
; draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr
Subject: Re: [Lsr] W
Hi, Acee and authors of this draft:
Want to know why the “IS-IS Flexible Algorithm Prefix Metric Sub-TLV” and “OSPF
Flexible Algorithm Prefix Metric Sub-TLV” etc that defined in sec 8-10 of
draft-ietf-lsr-flex-algo can’t be used to accomplish the same effect?
Aijun Wang
>> > On F
o
all routers on the LAN should be changed.
4. DRothers use the updated neighbor metric to calculate the SPF path to
the original mentioned router(Router A), push the traffic away to the mentioned
router(Router A)
Similar procedures as RFC8500. Is there any issues?
Best Regards
Aiju
ee the so-called “separate document”.
And, based on the discussions, I think there is no reason to differentiate the
solution for IS-IS and OSPF on LAN interface.
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> mailto:lsr-boun
value) appointed by
the “Reverse Metric”. The “W” bit can be preserved, to signal whether only the
interface to the advertised router be changed, or all the routers on the LAN
will be influenced.
Best Regards
Aijun Wang
China Telecom
From: lsr-boun...@ietf.org On Behalf Of Acee Lindem
Hi, Acee:
The questions raised at
https://mailarchive.ietf.org/arch/msg/lsr/RlHphXCwxMbgGvcBV_m24xiDzS0/ has not
been answered.
Aijun Wang
China Telecom
> On May 2, 2022, at 23:00, Acee Lindem (acee)
> wrote:
>
>
> The WG last call has completed. We will submit an updated
-Flex effect then.
So, what’s the additional value of the IP-Flexalgo draft then?
Aijun Wang
China Telecom
> On May 3, 2022, at 14:46, Peter Psenak
> wrote:
>
> Aijun,
>
>> On 03/05/2022 00:47, Aijun Wang wrote:
>> Hi, Acee:
>> The questions raised at
>>
the FAPM
and the associated SID, the MPLS-based forwarding will be selected.
Why can’t they coexist?
Aijun Wang
China Telecom
> On May 3, 2022, at 16:05, Peter Psenak
> wrote:
>
> Aijun,
>
>> On 03/05/2022 09:59, Aijun Wang wrote:
>> Hi, Peter:
>> The defi
Hi, Peter:
I think the logic is the following:
FAPM is the sub-TLV of TLV 135,235,236 and 237, then it extends these TLVs for
advertising prefixes in algorithm 0 to other Flexible Algorithm.
Then I see no reason to define the new top-TLV to encoding the similar
information.
Aijun Wang
China
an IPv4 Algorithm Prefix Reachability
TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
when installing entries in the forwarding plane.
It is obvious that any prefixes can be advertised in either TLVs, what’s the
necessary to define the new one?
Aijun Wang
China Telecom
Defining new algorithm also requires the all the node upgrades. Your argument
seems not reasonable.
Aijun Wang
China Telecom
> On May 4, 2022, at 11:49, Parag Kaneriya wrote:
>
> Mixing data plan using same TLV may lead to forwarding issue. if you do so
> it is required to upg
Hi, Les:
Aijun Wang
China Telecom
> On May 4, 2022, at 07:12, Les Ginsberg (ginsberg) wrote:
>
>
> Aijun –
>
> I am not an author of the draft – and so cannot speak on behalf of the draft
> authors.
> But here is my response as WG member.
>
> You
Hi, Gyan:
Aijun Wang
China Telecom
> On May 5, 2022, at 02:48, Gyan Mishra wrote:
>
>
>
> Hi Aijun
>
> Section 6 describes why as Les has mentioned that you need a new top level
> TLV for OSPF and ISIS for IP Flex Algo Reachability advertisement to
> disambig
eager to hear your additional comments/suggestions.
If there is no more concerns for the updated version, we want to ask Chairs to
forward it then.
Thanks in advance.
Aijun Wang
China Telecom
> On May 16, 2022, at 19:02, internet-dra...@ietf.org wrote:
>
>
> A New Inter
the authors and all the reviewers’ and shepherd’s
efforts, but think this is not the right direction to accomplish the aim.
Aijun Wang
China Telecom
> On May 16, 2022, at 19:50, Acee Lindem (acee)
> wrote:
>
>
> Hi Aijun,
>
> We need to support mixed deployments of r
Hi, Acee:
Would you like to give one example to support your “loop” assertions?
Aijun Wang
China Telecom
> On May 16, 2022, at 23:41, Acee Lindem (acee)
> wrote:
>
>
>
>
> From: Aijun Wang
> Date: Monday, May 16, 2022 at 11:35 AM
> To: Acee Lindem , John S
d. Seems obvious to me.
>
> thanks,
> Peter
>
>
>
>
>> On 16/05/2022 17:35, Aijun Wang wrote:
>> Hi, Acee:
>> I am curious that you are so hurry to forward this document.
>> The updated document just describes the followings:
>> (https://datatracker.ietf
two years, there is no reason to discuss again the similar
procedures and the later work should respect the former’s efforts.
If you agree, we can discuss the details of convergence offline. If you don’t
agree, we can discuss these solutions openly within the WG list.
Aijun Wang
China
router
be upgraded. And the “Max-Value” solution doesn’t necessarily indicate the
prefix is lost. We should announce such information explicitly.
We can also discuss other convergence solutions.
Aijun Wang
China Telecom
> On Jun 7, 2022, at 20:34, Peter Psenak wrote:
>
>
when
they don’t understand the PUA information.
And, when all the routers be upgraded(which are all necessary for both
proposals) to support the PUA information , the UPA information can be omitted.
Aijun Wang
China Telecom
> On Jun 7, 2022, at 23:59, Peter Psenak wrote:
>
> Aijun,
Hi, Peter:
Here I want to ask you one question:
If the specified detailed prefix doesn’t exist in the receiver’s route table,
what the receiver will do when it receives the UPA information of this
specified prefix?
Aijun Wang
China Telecom
> On Jun 10, 2022, at 23:16, Peter Psenak wr
behavior of
the receiver—-The specified prefix may still also be reachable via the summary
address.
Wrt the any of the above situations, the problem described at the beginning of
the draft isn’t solved, Right?
Aijun Wang
China Telecom
> On Jun 13, 2022, at 21:14, Peter Psenak wrote:
>
&g
within one area to be upgraded is that it
want to avoid the situations when the router doesn’t recognize PUA message and
misbehave. We are considering the convergence of PUA/UPA solutions, which may
relax such requirements during deployment.
Aijun Wang
China Telecom
> On Jun 14, 2022, at 16
Hi, Peter:
If the prefix is still reachable via the summary address, no additional action
should be triggered.
In conclusion, UPA just tell the receiver that the detailed prefix is missing,
not the detailed prefix unreachable.
Aijun Wang
China Telecom
> On Jun 14, 2022, at 15:12, Pe
Hi, Robert:
Agreed. The potential usages of PUA/UPA are not only PE routers(for BGP PIC),
but also prevalent Tunnel technologies(GRE/SRv6).
All these nodes are important and we can’t punches so many holes in the summary
range.
Aijun Wang
China Telecom
> On Jun 14, 2022, at 22:43, Rob
consider all such prefixes unreachable? This is certainly not the aim
of the IP FlexAlgo document.
In conclusion, the prefixes unreachable information should be indicated
explicitly by other means, as that introduced in the PUA draft.
Aijun Wang
China Telecom
> On Jun 15, 2022, at 17:09, Pe
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
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
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
ilure node. 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,
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
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, Robert:
The ABR can detect the prefix unreachable via the SPF calculation once it
receives the LSA for link or node failure. What’s the necessary to run
multi-hop BFD among ABR and other PEs?
Aijun Wang
China Telecom
> On Jul 7, 2022, at 20:03, Peter Psenak
> wrote:
>
> O
s.
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
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
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
ion method.
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-annouc
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
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
PUAM 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
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
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,
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
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
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 after the recent c
.
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
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
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
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
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
. 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
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
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 Extension
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
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
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
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)&
.
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
, 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
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
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
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
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
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
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-
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]
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
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
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
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
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
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
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
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
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
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
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, 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
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
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
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
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
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:
>
>
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
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, 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
://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
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
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
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.
://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
抄
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
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
-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
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
1 - 100 of 638 matches
Mail list logo
