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 <[email protected]>
Sent: Wednesday, July 17, 2024 7:05 PM
To: Christian Hopps <[email protected]>; Aijun Wang <[email protected]>
Cc: Tony Przygienda <[email protected]>; Acee Lindem <[email protected]>;
Les Ginsberg (ginsberg) <[email protected]>; Peter Psenak (ppsenak)
<[email protected]>; Yingzhen Qu <[email protected]>; lsr-chairs
<[email protected]>; shraddha <[email protected]>; lsr <[email protected]>
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. I've given thoughtful
consideration to all the points you've raised.
In response, I am trying to explain the solution of
draft-cheng-lsr-ospf-adjacency-suppress. Hope it can address your concerns.
I've aimed to be comprehensive, but if I've missed anything or misunderstood
any aspect, please don't 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 <[email protected]<mailto:[email protected]>>
收件人：Aijun Wang <[email protected]<mailto:[email protected]>>
抄 送: Christian Hopps <[email protected]<mailto:[email protected]>>,Tony
Przygienda <[email protected]<mailto:[email protected]>>,Acee Lindem
<[email protected]<mailto:[email protected]>>,"'Les Ginsberg (ginsberg)'"
<[email protected]<mailto:[email protected]>>,Liyan Gong
<[email protected]<mailto:[email protected]>>,"'Peter Psenak
(ppsenak)'" <[email protected]<mailto:[email protected]>>,Yingzhen Qu
<[email protected]<mailto:[email protected]>>,lsr-chairs
<[email protected]<mailto:[email protected]>>,shraddha
<[email protected]<mailto:[email protected]>>,lsr
<[email protected]<mailto:[email protected]>>
发送时间：2024-07-17 21:21:26
主题：[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About Premature aging of LSA
and Purge LSA
"Aijun Wang" <[email protected]<mailto:[email protected]>>
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 Tony's
> assertion?
Aijun,
I must have mis-interpreted you, I read that you were asking for for references
backing up Tony's assertion that originating purges from the non-owning routers
was something to avoid... That's 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
> can't we try the neighbor proxy solution?
>
> For Acee's 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 don't clear the stale LSPs in advance by the proxy neighbor?
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
>
> -----邮件原件-----
> 发件人: [email protected]<mailto:[email protected]>
> [mailto:[email protected]] 代表 Christian Hopps
> 发送时间: 2024年7月16日 22:24
> 收件人: Tony Przygienda <[email protected]<mailto:[email protected]>>
> 抄送: Aijun Wang <[email protected]<mailto:[email protected]>>;
> Acee Lindem <[email protected]<mailto:[email protected]>>;
> Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
> Liyan Gong
> <[email protected]<mailto:[email protected]>>; Peter Psenak
> (ppsenak) <[email protected]<mailto:[email protected]>>;
> Yingzhen Qu <[email protected]<mailto:[email protected]>>;
> lsr-chairs <[email protected]<mailto:[email protected]>>;
> shraddha <[email protected]<mailto:[email protected]>>;
> [email protected]<mailto:[email protected]>
> 主题: [Lsr] Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and
> Purge LSA
>
>
> Tony Przygienda <[email protected]<mailto:[email protected]>> 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
>> ;'-) 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 ;-)
>
> Here's 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 <[email protected]
<mailto:[email protected]%0b>>>> 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 <
>> [email protected]<mailto:[email protected]>> 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. Let's not go there
>>
>> -- tony
Subject：[Lsr] Re: 答复: Re: [Proxy of LSA Originator]Re: About Premature aging of
LSA and Purge LSA
"Aijun Wang" <[email protected]<mailto:[email protected]>>
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 Tony's
> assertion?
Aijun,
I must have mis-interpreted you, I read that you were asking for for references
backing up Tony's assertion that originating purges from the non-owning routers
was something to avoid... That's 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
> can't we try the neighbor proxy solution?
>
> For Acee's 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 don't clear the stale LSPs in advance by the proxy neighbor?
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
>
> -----邮件原件-----
> 发件人: [email protected]<mailto:[email protected]>
> [mailto:[email protected]] 代表 Christian Hopps
> 发送时间: 2024年7月16日 22:24
> 收件人: Tony Przygienda <[email protected]<mailto:[email protected]>>
> 抄送: Aijun Wang <[email protected]<mailto:[email protected]>>;
> Acee Lindem <[email protected]<mailto:[email protected]>>;
> Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
> Liyan Gong
> <[email protected]<mailto:[email protected]>>; Peter Psenak
> (ppsenak) <[email protected]<mailto:[email protected]>>;
> Yingzhen Qu <[email protected]<mailto:[email protected]>>;
> lsr-chairs <[email protected]<mailto:[email protected]>>;
> shraddha <[email protected]<mailto:[email protected]>>;
> [email protected]<mailto:[email protected]>
> 主题: [Lsr] Re: [Proxy of LSA Originator]Re: About Premature aging of LSA and
> Purge LSA
>
>
> Tony Przygienda <[email protected]<mailto:[email protected]>> 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
>> ;'-) 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 ;-)
>
> Here's 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 <[email protected]
<mailto:[email protected]%0b>>>> 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 <
>> [email protected]<mailto:[email protected]>> 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. Let's not go there
>>
>> -- tony
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
