Hey Acee
1. Will do 2. I look @ your suggested changes for sure. Generally, I think starting to enumerate “cases” will be far more confusing since it’s easier to implement “rules” rather than try to figure out how the cases are supposed to work. Hence normative rules are given. If you think we need more “MUST” tell me. 3. Per spec it can, I don’t know any major commercial implementations that would allow that but for completeness sake it’s included & don’t forget the routers “in the middle” are L1 only so it’s entirely viable to partition the area for L2 purposes by setting bunch overload bits on the “routers in the middle L1 only” --- tony From: "Acee Lindem (acee)" <[email protected]> Date: Friday, 3 December 2021 at 16:55 To: Antoni Przygienda <[email protected]> Cc: "[email protected]" <[email protected]> Subject: WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-06 [External Email. Be cautious of content] Speaking as WG member: I have already supported publication. I have a couple comments: 1. Can you add “leave” to the glossary in section 2? 2. Section 5.2 is a bit hard to read. I have some suggested changes in my editorial comments but it would be good to expand the cases into smaller chunks and make state the overall goals ahead rather than after the details. Your call though. 1. In section 7, would an IS-IS router really set the overload-bit in L1 but not L2? I’ve also attached some suggested editorial changes. Some of these are very subjective and I won’t feel bad if you don’t include them all. Thanks, Acee Juniper Business Use Only
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
