Hello, I support this draft, however would like the following aspect/scenario clarified.
Consider the scenario where both the neighbours on a p2p link initiate the reverse metric procedure (i.e. include the TLV in their hellos concurrently). How are implementations supposed to handle this? Normally the choice of metric conveyed via this TLV is based on a particular condition (which need not just be "overload") on the local router which requires the neighbour to use shift to using the reverse metric supplied. So when both neighbours initiate this process, it would be good to have the specification provide a deterministic behaviour since the reverse metric values provided may conflict in certain "non-overload" conditions. If both routers simply accept the value supplied by their neighbour, it may not achieve the original purpose/design of this triggering this mechanism? Following options come to my mind: a) when this condition is detected, none of the routers actually apply the reverse metric procedure b) when this condition is detected, the router with higher/lower system-id value (or some such tiebreaker) wins and the other withdraws its reverse metric (until then (a) applies) c) some mechanism/rule that is based on the value of metric offset specified perhaps (made harder since the actual metric is not signalled but the offset) which determines the "winner" so the other withdraws their TLV. Since the mechanism is not specific to overload conditions (where this is not an issue), it may be necessary for the specification to clarify this behaviour to ensure interoperability. Thanks, Ketan -----Original Message----- From: Isis-wg [mailto:[email protected]] On Behalf Of Christian Hopps Sent: 16 November 2017 04:13 To: [email protected] Cc: [email protected] Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07 The authors have asked for and we are starting a WG Last Call on https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/ which will last an extended 3 weeks to allow for IETF100. Thanks, Chris. _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
