Hi Les and All,
Thank you all for the discussions. I have been trying to understand the new
points，but unfortunately, so far, I have not been able to grasp their
advantages.
Can the authors update the better-idbx draft to elebrate the new points? This
will contribute to our understanding and evaluation of the work.
Additionally, I kindly suggest that the authors consider and reply the concerns
outlined in my previous email.
Best Regards,
Liyan
----邮件原文----发件人："Les Ginsberg \\(ginsberg\\)"
<ginsberg=40cisco....@dmarc.ietf.org>收件人：Liyan Gong
<gongli...@chinamobile.com>,Christian Hopps <cho...@chopps.org>,Aijun Wang
<wangai...@tsinghua.org.cn>抄 送: Tony Przygienda <tonysi...@gmail.com>,Acee
Lindem <acee.i...@gmail.com>,"Peter Psenak (ppsenak)"
<ppse...@cisco.com>,Yingzhen Qu <yingzhen.i...@gmail.com>,lsr-chairs
<lsr-cha...@ietf.org>,shraddha <shrad...@juniper.net>,lsr
<lsr@ietf.org>发送时间：2024-07-22 04:43:54主题：[Lsr] Re: 答复: Re: [Proxy of LSA
Originator]Re: About Premature aging of LSA and Purge LSA
Liyan –
Thanx for the thoughtful post.
There are two issues associated with the non-stateful restart of a router:
1)Ensuring that stales LSAs from the previous incarnation are flushed/updated
before paths via the restarting router are calculated by nodes in the network.
2)Allowing for forwarding plane update time on the restarting router to
complete before paths via the restarting router are installed into the
forwarding planes of other routers in the network.
The better-idbx draft addresses #1 – and does so in a backwards compatible way
– which is a significant win.
The adj-suppress draft addresses #2 – though it requires cooperation from the
neighbors of the restarting router.
Up to now, I have advocated for a combination of both solutions – whether in
two drafts or a single combined draft.
However, Acee has pointed out that the restarting router could – without
requiring changes on the neighbors – initially generate new versions of its
LSAs (particularly the Router LSA) which omit advertisement of the newly
acquired neighbors until the forwarding plane has been populated on the
restarting router. This addresses #2 above.
Given that Acee seems agreeable to add text into better-idbx (non-normative) to
mention this option, I now feel that the introduction of the SA bit is not
required. It can still be argued (as you have below) that use of the SA bit
may more reliably address flooding delays, but the added benefits seem minimal
to non-existent. And Acee’s proposal has the added benefits of not requiring
changes on the neighbors. It also likely makes it easier for the restarting
router to introduce special SPF logic to utilize the local adjacencies even
though they are not currently advertised – which is necessary for the
restarting router to populate its forwarding plane in advance of sending LSAs
which will actually attract traffic.
As a matter of history, the SA bit was introduced to IS-IS back in RFC 5306.
Since IS-IS does not have database exchange as a requirement to bring an
adjacency up, something new had to be introduced to address the startup issue.
SA bit was considered less disruptive than introducing non-backwards compatible
changes to the adjacency state machine. Since IS-IS has the Overload Bit to
prevent other routers from prematurely using the restarting router for transit
traffic, there was no need to use the SA bit for that purpose. Since OSPF does
not have the equivalent of the Overload bit, the additional step of having the
restarting router initially not advertise its adjacencies is needed.
If you can convince the authors of better-idbx to add the SA bit, I would be
fine with that – but it is hard to strongly advocate for that at this point.
Les
From: Liyan Gong <gongli...@chinamobile.com> Sent: Wednesday, July 17, 2024
7:05 PM To: Christian Hopps <cho...@chopps.org> Aijun Wang
<wangai...@tsinghua.org.cn> Cc: Tony Przygienda <tonysi...@gmail.com> Acee
Lindem <acee.i...@gmail.com> Les Ginsberg (ginsberg) <ginsb...@cisco.com> Peter
Psenak (ppsenak) <ppse...@cisco.com> Yingzhen Qu <yingzhen.i...@gmail.com>
lsr-chairs <lsr-cha...@ietf.org> shraddha <shrad...@juniper.net> lsr
<lsr@ietf.org> Subject: Re:[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About
Premature aging of LSA and Purge LSA
Hi All，
Thank you for all your insightful discussions. I39ve given thoughtful
consideration to all the points you39ve raised.
In response, I am trying to explain the solution of
draft-cheng-lsr-ospf-adjacency-suppress. Hope it can address your concerns.
I39ve aimed to be comprehensive, but if I39ve missed anything or misunderstood
any aspect, please don39t hesitate to correct me or provide additional feedback.
1. As we have discussed, it is difficult to find a precise delay time because
of the uncertainty of flooding, so we introduce a timer to control it. It has
several benefits:
1)it can avoid the complexity of realization.
2)it can reslove the remote neighbor scenario
3)it facilitates for forwarding plane programming
4)it can avoid the neighbor machine deadlock
5)it is valid for the whole restart router/ospf process,we do not need to start
the timer for each interface.
6)it is valid for all types of lsas. As we have explained previously, even
though router-Lsas and network-Lsas have been re-originated, Type 5 routes may
still have problems.
2. This solution is controlled by the restart router. The neighbors only need
to respond to the restart router.The advantages are reflected in the following
aspects.
1) It complies with other extended features, such as GR, NSR,stub-router,
reverse-metric. Usually，if you do/not want traffic to be sent to a specific
router, the controls are on the router itself, not neighbor routers.
Controlling on the same side can prevent the neighbor routers from identifying
different features and performing special processing when some features take
effect at the same time.
2) Restarting router can distinguish interface restart and router restart, but
the neighbor router can not.
3) It can be enabled by default on the restart router. Or else, The neighbor
routers should enable the configuration by default, since the unexpected
restart can happen at any time. Further more, the neighbor routers must
resolve the upper question 2).
4) For multi-neighbors scenario, it can prevent the function failure that occur
when one certain neighbor is not configured.
Best Regards,
Liyan
----邮件原文---- 发件人：Christian Hopps <cho...@chopps.org> 收件人：Aijun Wang
<wangai...@tsinghua.org.cn> 抄 送: Christian Hopps <cho...@chopps.org>,Tony
Przygienda <tonysi...@gmail.com>,Acee Lindem <acee.i...@gmail.com>,"39Les
Ginsberg (ginsberg)39" <ginsb...@cisco.com>,Liyan Gong
<gongli...@chinamobile.com>,"39Peter Psenak (ppsenak)39"
<ppse...@cisco.com>,Yingzhen Qu <yingzhen.i...@gmail.com>,lsr-chairs
<lsr-cha...@ietf.org>,shraddha <shrad...@juniper.net>,lsr <lsr@ietf.org>
发送时间：2024-07-17 21:21:26 主题：[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re:
About Premature aging of LSA and Purge LSA "Aijun Wang"
<wangai...@tsinghua.org.cn> writes: > Hi, Chirs: > > The links that you
provided has no relation for the discussions of "proxy of LSA originator".
Would you like to provide other pointer to support Tony39s assertion? Aijun, I
must have mis-interpreted you, I read that you were asking for for references
backing up Tony39s assertion that originating purges from the non-owning
routers was something to avoid... That39s what my links were pointing at. If
that was not relevant then please disregard. Thanks, Chris. > Hi, Tony: > > I
found none discussions that you mentioned within IETF mail list. Would you like
to give me some pointer(Drafts/RFCs/Discussion Topics) to support your
assertion? > > And, we have now the "area proxy for IS-IS
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-12";, why
can39t we try the neighbor proxy solution? > > For Acee39s proposal, it
requires all 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 don39t clear the stale LSPs in advance by the proxy
neighbor? > > Best Regards > > Aijun Wang > China Telecom > > > -----邮件原件-----
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
Christian Hopps > 发送时间: 2024年7月16日 22:24 > 收件人: Tony Przygienda
<tonysi...@gmail.com> > 抄送: Aijun Wang <wangai...@tsinghua.org.cn> Acee Lindem
<acee.i...@gmail.com> > Les Ginsberg (ginsberg) <ginsb...@cisco.com> Liyan Gong
> <gongli...@chinamobile.com> Peter Psenak (ppsenak) <ppse...@cisco.com> >
Yingzhen Qu <yingzhen.i...@gmail.com> lsr-chairs <lsr-cha...@ietf.org> >
shraddha <shrad...@juniper.net> lsr@ietf.org > 主题: [Lsr] Re: [Proxy of LSA
Originator]Re: About Premature aging of LSA and Purge LSA > > > Tony Przygienda
<tonysi...@gmail.com> writes: > >> Aijun, simply check the amount of RFCs and
vendor knobs on proxy purge >> origination ID, security signatures, spec
implementation deviations >> etc. which will give you an indication lots of bad
things happened >> with it to good and bad people running large networks alike
>> 39-) AFAIR lots of discussions were on the IGP lists in last 20 years >>
when "interesting" stuff with proxy purges happened in the field, last >> I
dealt with was about 3-4 years ago only -) > > Here39s a couple: > >
https://www.rfc-editor.org/rfc/rfc3719.html#section-7 >
https://www.rfc-editor.org/rfc/rfc3719.html#section-8 > > Thanks, > Chris. > >>
>> Beside the usual "oh, yeah, implementation bugs here galore" it all >> goes
back to the SPOT architectural principle which, when deviated >> from, always
ends up in cache synchronization problems which can be >> solved but are highly
complex, expose lots of attack vectors and >> ultimately lead to a less
available solution along the lines of CAP >> paradigm I mentioned earlier. >>
>> -- tony >> >> On Mon, Jul 15, 2024 at 4:28PM Aijun Wang
<wangai...@tsinghua.org.cn >>> wrote: >> >> Hi, Tony: >> >> Would you
like to provide some detail explanations to support >> your asserts? >> >>
Aijun Wang >> China Telecom >> >> >> On Jul 15, 2024, at 20:23,
Tony Przygienda < >> tonysi...@gmail.com> wrote: >> >> >> proxy
purges was one of the worst ideas in IGP operationally >> speaking for
people dealing with this stuff in real networks >> for last 20+ years
and still is. Let39s not go there >> >> -- tony Subject：[Lsr] Re: 答复:
Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and Purge LSA
"Aijun Wang" <wangai...@tsinghua.org.cn> writes: > Hi, Chirs: > > The links
that you provided has no relation for the discussions of "proxy of LSA
originator". Would you like to provide other pointer to support Tony39s
assertion? Aijun, I must have mis-interpreted you, I read that you were asking
for for references backing up Tony39s assertion that originating purges from
the non-owning routers was something to avoid... That39s what my links were
pointing at. If that was not relevant then please disregard. Thanks, Chris. >
Hi, Tony: > > I found none discussions that you mentioned within IETF mail
list. Would you like to give me some pointer(Drafts/RFCs/Discussion Topics) to
support your assertion? > > And, we have now the "area proxy for IS-IS
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-12";, why
can39t we try the neighbor proxy solution? > > For Acee39s proposal, it
requires all 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 don39t clear the stale LSPs in advance by the proxy
neighbor? > > Best Regards > > Aijun Wang > China Telecom > > > -----邮件原件-----
> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表
Christian Hopps > 发送时间: 2024年7月16日 22:24 > 收件人: Tony Przygienda
<tonysi...@gmail.com> > 抄送: Aijun Wang <wangai...@tsinghua.org.cn> Acee Lindem
<acee.i...@gmail.com> > Les Ginsberg (ginsberg) <ginsb...@cisco.com> Liyan Gong
> <gongli...@chinamobile.com> Peter Psenak (ppsenak) <ppse...@cisco.com> >
Yingzhen Qu <yingzhen.i...@gmail.com> lsr-chairs <lsr-cha...@ietf.org> >
shraddha <shrad...@juniper.net> lsr@ietf.org > 主题: [Lsr] Re: [Proxy of LSA
Originator]Re: About Premature aging of LSA and Purge LSA > > > Tony Przygienda
<tonysi...@gmail.com> writes: > >> Aijun, simply check the amount of RFCs and
vendor knobs on proxy purge >> origination ID, security signatures, spec
implementation deviations >> etc. which will give you an indication lots of bad
things happened >> with it to good and bad people running large networks alike
>> 39-) AFAIR lots of discussions were on the IGP lists in last 20 years >>
when "interesting" stuff with proxy purges happened in the field, last >> I
dealt with was about 3-4 years ago only -) > > Here39s a couple: > >
https://www.rfc-editor.org/rfc/rfc3719.html#section-7 >
https://www.rfc-editor.org/rfc/rfc3719.html#section-8 > > Thanks, > Chris. > >>
>> Beside the usual "oh, yeah, implementation bugs here galore" it all >> goes
back to the SPOT architectural principle which, when deviated >> from, always
ends up in cache synchronization problems which can be >> solved but are highly
complex, expose lots of attack vectors and >> ultimately lead to a less
available solution along the lines of CAP >> paradigm I mentioned earlier. >>
>> -- tony >> >> On Mon, Jul 15, 2024 at 4:28PM Aijun Wang
<wangai...@tsinghua.org.cn >>> wrote: >> >> Hi, Tony: >> >> Would you
like to provide some detail explanations to support >> your asserts? >> >>
Aijun Wang >> China Telecom >> >> >> On Jul 15, 2024, at 20:23,
Tony Przygienda < >> tonysi...@gmail.com> wrote: >> >> >> proxy
purges was one of the worst ideas in IGP operationally >> speaking for
people dealing with this stuff in real networks >> for last 20+ years
and still is. Let39s not go there >> >> -- tony
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
