Re: [Lsr] LEEF bit behavior) RE: I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

Huaimo -

Thanx for providing the inspiration for advertising LEEF.

The draft is very explicit in saying that LEEF advertisements are for diagnostic purposes only and do NOT alter dynamic flooding state. I think there are good reasons for this. Consider the possibilities when advertised LEEF state is not as expected:

1)LEEF bit is set for an edge which is NOT part of the flooding topology

We have a node which supports dynamic flooding but indicates it is flooding on a link which is NOT part of the flooding topology. This means unnecessary flooding is occurring. If the neighbor enables flooding on that link because it has received LEEF bit, it is only adding to the amount of unnecessary flooding - which is neither useful nor desirable.

2)LEEF bit is NOT set for an edge which is part of the flooding topology

We have a node which supports dynamic flooding but it fails to enable flooding on a link which is part of the flooding topology. This means that the implementation has a bug of some sort:

*         it does not correctly process the flooding path advertisement (centralized mode)

*         it does not correctly calculate the flooding topology (distributed mode)

When interpreting the LEEF bit (presumably) set by the neighbor, the receiving (buggy) node cannot distinguish between case #1 above and case #2 i.e., it cannot tell whether it is correct and the neighbor is wrong or vice versa. If it could it would have set the LEEF bit as it would know this link is part of the flooding topology.

Advertising flooding state is useful for diagnostic purposes - but it is an unreliable tool if used to try to "correct" flooding state.

So we do not want to add the behavior you suggest.

   Les


From: Huaimo Chen <[e-mail]>
Sent: Wednesday, May 22, 2019 1:52 PM
To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]
Subject: LEEF bit behavior) RE: [Lsr] I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt


Hi Les,


     Thank you very much for adding the LEEF bit into the draft based on the FT bit for a link. The bit advertised by one end node of the link indicates whether the link is on the flooding topology.

Would you mind adding the behavior below for checking and handling the inconsistency of the flooding topology through using this bit?

For a link L between node A and node B, if the LEEF bit for link L advertised by node A is different from the one advertised by node B, then the flooding topology is inconsistent, the node receiving the LEEF bit set to one for link L from the other node adds link L on the flooding topology temporarily.

If one of the two nodes receives the LEEF bit set to one for link L from the other, but advertises the LEEF bit set to zero for link L for a given time such as 5 seconds, then a warning is issued or logged.



Best Regards,

Huaimo

-----Original Message-----

From: Lsr [mailto:[e-mail]] On Behalf Of Les Ginsberg (ginsberg)

Sent: Tuesday, May 21, 2019 1:56 PM

To: [e-mail]<mailto:[e-mail]>

Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt



Folks -



Major changes in this version include:



1)Added support for LANs as part of the flooding tropology



2)Added support for advertising what links are enabled for flooding at each node. This is based on a proposal in draft-cc-lsr-flooding-reduction (the FT bit) but we have defined it to be advertised associated with a link rather than in hellos. This is to allow management tools to more easily verify correctness of the flooding topology on each node. It does NOT change operational state in any way.



3)Added some text around rate limiting temporary flooding when attempting to repair a partitioned flooding topology.



    Les