Aijun -
What is missing in this discussion is a definition of the problem to be solved.
Current draft relies on event driven updates to LSPs - the same mechanism that
has been used for 30 years to detect all manner of changes in the network.
Before defining a "solution" (let alone voting for which one is best) it would
be good to have a definition of what problem is unaddressed currently.
Les
> -----Original Message-----
> From: Lsr <[email protected]> On Behalf Of Aijun Wang
> Sent: Monday, May 27, 2019 11:16 PM
> To: 'Tony Li' <[email protected]>; 'Robert Raszuk'
> <[email protected]>
> Cc: [email protected]
> Subject: [Lsr] 答复: Option B from "Migration between normal flooding and
> flooding reduction"
>
> Hi, Tony:
>
> How the receiver judge the leader has stopped advertising the Area Leader
> sub-TLV? Do you need some timers?
> >From the current discussion, I think the explicit instruction that proposed
> >by
> Huaimo is more acceptable.
>
>
> Best Regards.
>
> Aijun Wang
> Network R&D and Operation Support Department
> China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
>
> -----邮件原件-----
> 发件人: Tony Li [mailto:[email protected]]
> 发送时间: 2019年5月27日 12:20
> 收件人: Robert Raszuk
> 抄送: [email protected]
> 主题: Re: [Lsr] Option B from "Migration between normal flooding and
> flooding reduction"
>
>
> Hi Robert,
>
> > The current draft is pretty robust in terms of area leader election. It also
> says that "Any node that is capable MAY advertise its eligibility to become
> Area Leader”
>
>
> Correct. This can be all systems. It can be one. For redundancy, a few would
> be sensible.
>
>
> > With that can you confirm the procedure to "resign" as area leader ?
>
>
> Stop advertising the Area Leader sub-TLV. It’s that simple.
>
>
> > Especially that under those circumstances just having active area leader to
> resign clearly is not enough to change given flooding scheme.
>
>
> If there are multiple potential area leaders, then all of them would have to
> resign.
>
>
> > In some deployments all eligible nodes may advertise such capability which
> in turn the "resign" procedure would require NMS action to disable such
> capability by configuration and re-flooding it. Not that I am advocating it
> nor
> see need for complex migration procedures, but just would like to better
> understand the "resign" part.
>
>
> Correct, this is rightfully an NMS operation.
>
> Tony
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
