Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

[Christian Hopps <[e-mail]>]

Here are my comments on -08. The most important one would be the 
M-ISIS
discrepancy.

- 3.1 " If an IS-IS router is configured to originate a TE Default 
  Metric
   sub-TLV for a link, but receives a Reverse Metric TLV from its
   neighbor that does not contain a TE Default Metric sub-TLV, 
   then the
   IS-IS router MUST NOT change the value of its TE Default Metric 
   sub-
   TLV for that link."

   - so this is a reversal from -07, where it said it MUST add the 
   metric offset
     value to the TE default metric. Note this is also not updated 
     in M-ISIS section.

- 3.1 "Routers MUST scan the Metric Offset value and TE sub-TLVs 
  in all
   subsequently received Reverse Metric TLVs.  If changes are 
   observed
   by a receiver of the Reverse Metric TLV in the Metric Offset 
   value or
   TE Default Metric sub-TLV value, the receiving router MUST 
   update its
   advertised IS-IS default metric or Traffic Engineering 
   parameters in
   the appropriate TLVs, recompute its SPF tree and flood new LSPs 
   to
   other IS-IS routers.

   - I don't like this, why do we have to say, "pay attention to 
   and act on
     updates to the value?" When do we *not* do this in routing 
     protocols?

   - If we keep this text, change to "subsequently received IIH" 
   as one might
     read this meaning that we accept multiple TLVs per IIH which 
     we don't.

 - 3.2 "The Reverse Metric TLV is applicable to Multi-Topology 
 IS-IS (M-ISIS)
   [RFC5120] capable point-to-point links.  If an IS-IS router is
   configured for M-ISIS it MUST send only a single Reverse Metric 
   TLV
   in IIH PDUs toward its neighbor(s) on the designated link that 
   is
   about to undergo maintenance."

   - There are other reasons to set the reverse metric (e.g., high 
   BER on
     receive).

 - 3.2 "If an M-ISIS router is configured to advertise TE Default 
 Metric
   sub-TLVs for one or more topologies, but does not receive a TE 
   Default Metric
   sub-TLV in a Reverse Metric TLV, then the M-ISIS router MUST 
   add the value in
   Metric Offset field of the Reverse Metric TLV to each of the TE 
   Default
   Metric sub-TLVs for all topologies. The M-ISIS should flood its 
   newly updated
   MT IS TLVs and recompute its SPF/CSPF accordingly."

   - This is opposite the changed behavior described in 3.1.


 - 3.4 P2P change says "Must Add" and removed the text about not 
 going to
   overload-max value. (2^24-1), should probably say "must add 
   according to the
   rules found in 3.1?


Thanks,
Chris.

Naiming Shen (naiming) <[e-mail]> writes:

> Hi Chris,
>
>> On Jan 11, 2018, at 1:19 AM, Christian Hopps 
>> <[e-mail]> wrote:
>>
>>
>> Naiming Shen (naiming) <[e-mail]> writes:
>>
>>> Hi,
>>>
>>> Sounds reasonable. At this stage of the draft, we’ll probably 
>>> skip this
>>> capability. If it is found needed later, it can be added 
>>> easily. I suspect
>>> there are a number of other things can be later ride on top of 
>>> this.
>>
>> Hi Naiming,
>>
>> Correct me if I'm wrong, but aren't you saying here that you 
>> would not
>> add the 2^24-1 functionality? I'm asking b/c you also just 
>> published a
>> new version -08 that appears to add this functionality. :)
>>
>> Was there any off-list discussion that led to the change of 
>> heart?
>
> Actually, this is not really a new functionality of the draft:-)
> We also removed the section 3.6 “Link Overload Attribute Bit” of
> sub-TLV of TLV 22 in the LSP. This change is due to several 
> factors:
>
> - the long discusion ongoing of OSPF mailing list of the name 
> “overload”,
> which has disagreement on what does this “overload” really 
> meant,
> and what to do if it’s “overloaded”. This version 7 borrowed 
> this from
> OSPF, and now we got requests also to reconsider the name of 
> this
> “Link Overload Attribute Bit”
>
> - More importantly we just realized that, to use this “overload” 
> bit in LSP,
> the backwards compatibility is not possible anymore, as in the 
> other
> “reverse-metric” feature which is all local to the link. So, if 
> we have to
> use this “overload” bit in LSP, we have also to define the 
> router
> “capabilities” to advertise this, and synchronize among 
> area/domain,
> which we really don’t want to do in ‘reverse-metric'
>
> - Third with this “U” bit, it achieves the same effect of the 
> “overload” bit,
>  since the neighbor can optionally set the (2^24-1) and take out 
>  the
>  link as ‘unusable’ for IGP or TE, while at the mean time keep 
>  the same
>  backwards compatibility in the area/domain, which is a very 
>  clean solution.
>
> - I have had long email/chat discussion on this with Les, since 
> we have
> seen the email, this (2^24-1) has been part of the comments 
> discussion
> during the last call. and at the time I didn’t think clearly and 
> mentioned on
> the list we wouldn't do that, but with all the above mentioned 
> reasons,
> we decided that is the right way to go. As mentioned, the reason 
> of doing
> that is not to handle the multi-area LDP/IGP sync kind of 
> use-case, but
> to support TE topology to take the link out just as in the 
> removed
> section 3.6 in ver 7.
>
> thanks.
> - Naiming
>
>>
>> Thanks,
>> Chris.
>>
>>> Regards,
>>> - Naiming
>>>
>>> On Dec 30, 2017, at 4:05 PM, Les Ginsberg (ginsberg) 
>>> <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>>
>>>
>>> From: Alexander Okonnikov 
>>> [mailto:[e-mail]]
>>> Sent: Saturday, December 30, 2017 3:34 PM
>>> To: Les Ginsberg (ginsberg) 
>>> <[e-mail]<mailto:[e-mail]>>
>>> Cc: Naiming Shen (naiming) 
>>> <[e-mail]<mailto:[e-mail]>>; 
>>> [e-mail]<mailto:[e-mail]>; Christian Hopps 
>>> <[e-mail]<mailto:[e-mail]>>; 
>>> [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [Isis-wg] WG Last Call for 
>>> draft-ietf-isis-reverse-metric-07
>>>
>>> Les,
>>>
>>>
>>> 31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg) 
>>> <[e-mail]<mailto:[e-mail]>> написал(а):
>>>
>>> Alex -
>>>
>>> From: Alexander Okonnikov 
>>> [mailto:[e-mail]]
>>> Sent: Saturday, December 30, 2017 3:06 PM
>>> To: Les Ginsberg (ginsberg) 
>>> <[e-mail]<mailto:[e-mail]>>
>>> Cc: Naiming Shen (naiming) 
>>> <[e-mail]<mailto:[e-mail]>>; 
>>> [e-mail]<mailto:[e-mail]>; Christian Hopps 
>>> <[e-mail]<mailto:[e-mail]>>; 
>>> [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [Isis-wg] WG Last Call for 
>>> draft-ietf-isis-reverse-metric-07
>>>
>>> Les,
>>>
>>>
>>>
>>> 31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg) 
>>> <[e-mail]<mailto:[e-mail]>> написал(а):
>>>
>>> Alex -
>>>
>>> From: Alexander Okonnikov 
>>> [mailto:[e-mail]]
>>> Sent: Saturday, December 30, 2017 2:38 PM
>>> To: Les Ginsberg (ginsberg) 
>>> <[e-mail]<mailto:[e-mail]>>
>>> Cc: Naiming Shen (naiming) 
>>> <[e-mail]<mailto:[e-mail]>>; 
>>> [e-mail]<mailto:[e-mail]>; Christian Hopps 
>>> <[e-mail]<mailto:[e-mail]>>; 
>>> [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [Isis-wg] WG Last Call for 
>>> draft-ietf-isis-reverse-metric-07
>>>
>>> Hi Les,
>>>
>>> Don't advertise link and advertise it with metric 2^24-1 makes 
>>> sense again. In the former case that link cannot be used for 
>>> TE LSPs, while in latter one it is possible. This is also 
>>> described in RFC 5305:
>>>
>>> "   If a link is advertised with the maximum link metric (2^24 
>>> - 1), this
>>> link MUST NOT be considered during the normal SPF computation. 
>>> This
>>> will allow advertisement of a link for purposes other than 
>>> building
>>> the normal Shortest Path Tree.  An example is a link that is
>>> available for traffic engineering, but not for hop-by-hop 
>>> routing."
>>>
>>> [Les:] I am well aware of this. My comment regarding (2^24 - 
>>> 1) is in the context of reverse metric. If the reason that you 
>>> want to advertise (2^24-1) is because the link is only 
>>> supposed to be used for TE purposes then this would already 
>>> have been done by the neighbor as part of their configuration 
>>> – and it has nothing to do with adjacency bringup.
>>> Idea was to temporarily disable IP forwarding on the link 
>>> while preserve ability to use link for other transport. An 
>>> example when we need it - IGP-LDP sync. If you configure 
>>> 2^24-1 on the neighbor, then link will be excluded from IP 
>>> topology permanently. Also, it is not clear for me how it 
>>> could be done on LAN.
>>>
>>>
>>> [Les:] My point is – if you do not want the link to be used at 
>>> all – even if only while waiting for LDP sync to complete – 
>>> then you simply don’t advertise the adjacency. In the case of 
>>> the LAN you don’t advertise the adjacency to the DIS – so 
>>> there is no 2-way connectivity on that circuit and no traffic 
>>> flows to/from the node via the interface in  question. It does 
>>> not matter what the neighbor/DIS is advertising.
>>> My point - to have ability to exclude link from IP topology, 
>>> but still use it in other topologies. This could be done by 
>>> advertising metric 2^24-1. If adjacency is not advertised, 
>>> then that link is excluded from all topologies, not only from 
>>> IP. In general my proposal is to make reverse-metric 
>>> functionality as flexible as possible and to don't restrict it 
>>> deliberately.
>>>
>>> [Les:] This is exactly what I object to. Reverse-metric is not 
>>> and should not be a general purpose mechanism to have one node 
>>> override the configuration of its neighbors for any and all 
>>> possible reasons. It has well defined use cases which the 
>>> draft describes  and its use should be limited to those cases.
>>>
>>> The additional use cases you have suggested can already be 
>>> handled by existing mechanisms which are local to each node 
>>> and that should always be the preferred means. The potential 
>>> for chaos that results when each node utilizes this mechanism 
>>> to adjust the SPF outcome on other routers based on its local 
>>> view of the current state of convergence is not something I 
>>> want to embrace.
>>>
>>> Les
>>>
>>>
>>>
>>> Regarding L1 circuit between L1/L2 routers - it is not always 
>>> possible or is not desired.
>>>
>>> [Les:] I was covering the example you provided. It was clear 
>>> from your example that although L2 only was enabled between 
>>> the L1/L2 routers, you were allowing intra-area traffic to 
>>> flow over that link.
>>> If you do not want intra-area traffic to flow over that link 
>>> at all, then you need to insure that L1 destinations are not 
>>> leaked into L2 – in which case the proposed change you are 
>>> suggesting for reverse-metric would not help.
>>>
>>> If you think you have a different example that justifies your 
>>> proposal I would be happy to review it – but the one you have 
>>> come up with isn’t compelling.
>>> Two L1/L2 routers could be geographically dispersed.
>>> [Les:] Only if the L1/L2 routers are in different areas – in 
>>> which case your example does not apply.
>>> Not necessary. There could be area represented by sub-ring 
>>> physical topology.
>>>
>>>
>>> There could be L2 subdomain which provides L2 path between 
>>> them. But sometimes it is not optimal to configure L1/L2 on 
>>> all transit L2 routers between two ones. Also, for redundancy 
>>> you will need to provide alternative L1 path in the core (to 
>>> avoid routing traffic via access).
>>>
>>> Another case, when having looped L1 is not desired - when R3 
>>> has reachability to the network via two ABRs (R1 and R2), and 
>>> R2 is closer to R3 than R1 to R3. In case link (path) from R3 
>>> to R2 is broken, it is more optimal from data path perspective 
>>> to reroute traffic to R1 rather than to R2 via R1. It is not 
>>> case for regular IP routing, but becomes sensitive when we 
>>> have deal with L2VPN services, such that MS-PW or H-VPLS, 
>>> where R1 and R2 are S-PEs or Hub PEs, respectively.
>>>
>>> [Les:] We are not discussing all possible network topologies. 
>>> The topic here is the Reverse-Metric draft and whether there 
>>> is a use case for a node to tell its neighbor to advertise 
>>> max-metric (2^24-1).
>>> Please stay on topic. If you have an example that justifies 
>>> your proposal I would like to hear it – but please stay 
>>> focused on this use case.
>>>
>>> Les
>>>
>>>
>>>
>>> Les
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>> 31 дек. 2017 г., в 1:33, Les Ginsberg (ginsberg) 
>>> <[e-mail]<mailto:[e-mail]>> написал(а):
>>>
>>> I strongly disagree with this proposed change.
>>>
>>> If you want to take the link totally out of the topology then 
>>> simply don’t advertise the adjacency. This works for both P2P 
>>> and LAN cases.
>>> This is why the draft states
>>>
>>> “a receiver of a
>>> Reverse Metric TLV MUST use the numerically smallest value of 
>>> either
>>> the sum of its existing default metric and the Metric Offset 
>>> value in
>>> the Reverse Metric TLV or (2^24 - 2)”
>>>
>>> There is no use case for (2^24 - 1).
>>>
>>> As for the L1/L2 example topology that Alex used to justify 
>>> his proposal, there is a much better way to prevent the 
>>> premature use of the L1 link. That is to enable L1 on the link 
>>> between the two L1L2 routers but configure a larger metric 
>>> (e.g. 100000) so that the L1/L2 link will only be used for L1 
>>> traffic when there is no viable L1 only link. There is no need 
>>> to use Reverse-Metric to do so and I believe this is an 
>>> inappropriate use of this extension.
>>>
>>> Les
>>>
>>>
>>> From: Isis-wg [mailto:[e-mail]] On Behalf Of 
>>> Naiming Shen (naiming)
>>> Sent: Saturday, December 30, 2017 11:59 AM
>>> To: Alexander Okonnikov 
>>> <[e-mail]<mailto:[e-mail]>>
>>> Cc: [e-mail]<mailto:[e-mail]>; Christian Hopps 
>>> <[e-mail]<mailto:[e-mail]>>; 
>>> [e-mail]<mailto:[e-mail]>
>>> Subject: Re: [Isis-wg] WG Last Call for 
>>> draft-ietf-isis-reverse-metric-07
>>>
>>>
>>> Hi Alex,
>>>
>>> Ok. We’ll add a bit to the flag (the 2nd bit) of the 
>>> ‘reverse-metric TLV’, to indicate
>>> the originator requesting the inbound direction of the link 
>>> not to be used and the
>>> metric should be raised by the peer to (2^24 - 1) regardless 
>>> the value of the ‘offset metric’
>>> value in the TLV.
>>>
>>> thanks.
>>> - Naiming
>>>
>>> On Dec 29, 2017, at 11:46 AM, Alexander Okonnikov 
>>> <[e-mail]<mailto:[e-mail]>> 
>>> wrote:
>>>
>>> Hi Naiming,
>>>
>>>
>>>
>>>
>>>
>>> 29 дек. 2017 г., в 6:10, Naiming Shen (naiming) 
>>> <[e-mail]<mailto:[e-mail]>> написал(а):
>>>
>>>
>>> Hi Alexander,
>>>
>>> Thanks for the comments, see more replies inline.
>>>
>>>
>>>
>>>
>>>
>>> On Dec 14, 2017, at 9:24 AM, Alexander Okonnikov 
>>> <[e-mail]<mailto:[e-mail]>> 
>>> wrote:
>>>
>>> Hi authors,
>>>
>>>
>>> I have some comments below regarding the draft:
>>>
>>>
>>> 1) Section 2: "There is currently only two Flag bits defined." 
>>> Per -07 only one flag is defined. S flag was deprecated since 
>>> version -06 (implicit signaling of presence of Sub-TLVs is 
>>> used via "Sub-TLV Len" field non-zero value. Text in the 
>>> beginning of the chapter 2 about flag S is to be removed as 
>>> well.
>>>
>>> NS> will fix.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2) Section 3.1: "In order to ensure that an individual TE link 
>>> is used as a link of last resort during SPF computation, ..." 
>>> I guess that you meant regular link rather than TE link.
>>>
>>> 3) For the same section: Per my understanding, this section 
>>> assumes that overloaded link will always be considered as 
>>> last-resort link. I.e. it cannot be excluded from topology (as 
>>> link with metric 2^24-1), unless originator of the TLV sets 
>>> appropriate bit in corresponding Link Attributes Sub-TLV (RFC 
>>> 5029) AND receiving ISs support that Sub-TLV. As alternative 
>>> it could be done by allowing for originator to specify reverse 
>>> metric special value 2^24-1 which would indicate to receivers 
>>> that the link is to be excluded from topology completely 
>>> rather than used as last resort. If reverse metric value is 
>>> between 0 - 2^24-2 then link could be used in path 
>>> calculation. The same rules for TE metric.
>>>
>>>
>>> NS> I don’t see there is much difference between not used or 
>>> last resort in the use cases we mentioned.
>>> also, this metric value is an ‘offset metric’ being added on 
>>> top of the existing local metric. It would not
>>> be always feasible to make the reverse-metric off by one to 
>>> mean two completely different operations.
>>>
>>> One use case when unusable link vs last resort one makes sense 
>>> is for IGP-LDP sync. Let's assume we have two-level IS-IS 
>>> domain. There are three ISs in the domain: R1 and R2 are L1/L2 
>>> ISs, and R3 is L1-only. R1 and R2 are connected to each other 
>>> via L2 circuit, and R3 is connected to R1 and R2 via L1 
>>> circuits. The link between R2 and R3 was broken and now is 
>>> being restored. While adjacency has not been established on 
>>> failed link, R3 has inter-area route towards R2's loopback. 
>>> Once adjacency has been established, but LDP session has not 
>>> yet, R3 and R2 maximize metric (2^24-2) on corresponding link. 
>>> But now R2 and R3 have routes to each other as L1 intra-area, 
>>> though with max metric. Because L1 intra-area route wins, R2 
>>> and R3 replace inter-area routes to each other by intra-area 
>>> ones. As a result, LDP LSPs are blackholed. On the other hand, 
>>> if two routers mark corresponding link as unusable (with 
>>> metric 2^24-1), they would use inter-area routes until IGP-LDP 
>>> sync will be com
>> pleted.
>>>
>>> An IS can make decision on whether to mark link as unusable or 
>>> as last resort, using the same principle as proposed in RFC 
>>> 6138.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 4) For the same section: The draft says that if originator 
>>> uses narrow metric-type, it should use value 63 as max-metric. 
>>> But on receiving reverse metric with such value receivers have 
>>> no idea whether this is "narrow" max-metric or offset 63 for 
>>> "wide" metric. I.e. the draft assumes that all ISs use the 
>>> same type of metric, and using of two metric types at the same 
>>> time is not covered. May be it would be appropriate to define 
>>> two Reverse Metric TLVs, like IS Neighbors TLV and Extended IS 
>>> Reachability TLV. Or to specify new flag to mark type of the 
>>> reverse metric.
>>>
>>>
>>> NS> to be simple, we have to assume a network is either run 
>>> wide or narrow. It can not be fixed. The
>>> document is trying to be complete to mention the ‘narrow’ 
>>> case.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 5) For the same section: It is not clear for me why DIS should 
>>> use min(63, (Metric + Reverse Metric)) while composing 
>>> pseudonode LSP. If DIS is configured for using "wide" 
>>> metric-type, it will use Extended IS Reachability TLVs for 
>>> describing its neighbors. Moreover, in this case DIS is not 
>>> obligated to still insert IS Neighbors TLVs in its Pseudonode 
>>> LSP (in addition to Extended IS Reachability TLVs) when it is 
>>> configured for "wide-only" mode.
>>>
>>> NS> agreed. will remove this, to keep the same goal as above, 
>>> to be simple. Not to mix them.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 6) For the same section: It is not clear for me why in case 
>>> when TE metric offset is not advertised in Reverse Metric TLV, 
>>> receiving IS must modify its TE metric by adding IGP reverse 
>>> metric value. In my mind, it would be straightforward to use 
>>> follow rule: if originator doesn't include TE metric part then 
>>> it doesn't wish to overload TE link, but only IGP link. For 
>>> example, originator advertises Reverse metric TLV as part of 
>>> IGP-LDP synchronization procedure (section 3.5). It is not 
>>> reason to impact TE properties (metric in this case) of the 
>>> link. Hence, originator could advertise Reverse metric TLV 
>>> without TE metric Sub-TLV, in order to signal that "TE metric 
>>> is left intact”.
>>>
>>> NS> sounds resonable. Will change this to say if the sub-TLV 
>>> of TE is not received, the TE properties will not change
>>> by receiving this ‘reverse-metric’ TLV.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 7) Section 3.3: The draft is not clear about handling of TE 
>>> metric by DIS. Usually DIS implementations don't insert TE 
>>> Sub-TLVs into Extended IS Reachability TLVs in Pseudonode LSP. 
>>> May be it would be better to add explicit text that: if DIS 
>>> receives TE metric Sub-TLV in Reverse Metric TLV it should 
>>> update TE Default Metric Sub-TLV value of corresponding 
>>> Extended IS Reachability TLV OR insert new one if it was not 
>>> present there.
>>>
>>> NS> To me, there is not much difference between DIS and other 
>>> nodes. Will try to add some words to that.
>>>
>>> thanks.
>>> - Naiming
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>> 30.11.2017 01:47, Naiming Shen (naiming) пишет:
>>>
>>>
>>>
>>>
>>> Hi Ketan,
>>>
>>> thanks for the support and comments. some clarification 
>>> inline,
>>>
>>>
>>>
>>>
>>>
>>> On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant) 
>>> <[e-mail]<mailto:[e-mail]>> wrote:
>>>
>>> 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?
>>> When you say if both sides initiated this ‘reverse metric’, 
>>> you implied
>>> there is a timing issue with this procedure in the draft.
>>>
>>> The value of this ‘metric offset’ (or whatever will be called) 
>>> of this TLV,
>>> is just a number. The draft does not say this number is equal 
>>> to the
>>> configured ‘metric’ value plus the received ‘reverse metrc’ 
>>> value, that
>>> would be non-deterministic and both sides would keep going up 
>>> until it’s
>>> overloaded:-)
>>>
>>> Each side of IS-IS link decides if it needs to send a ‘reverse 
>>> metric’ over the link,
>>> either in link-overloading case, or other cases. It’s a static 
>>> number, it does not
>>> depend on the other side sending a ‘reverse metric’ or not. 
>>> This both sides
>>> sending a ‘reverse-metric’ over a link is equivalent to an 
>>> operator provisions
>>> new metric (say both plus 10 to the old metric) on both sides 
>>> of the link at
>>> the same time, there is no non-determinitic thing in this.
>>>
>>> thanks.
>>> - Naiming
>>>
>>>
>>>
>>>
>>>
>>> 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:[e-mail]] On Behalf Of 
>>> Christian Hopps
>>> Sent: 16 November 2017 04:13
>>> To: [e-mail]<mailto:[e-mail]>
>>> Cc: [e-mail]<mailto:[e-mail]>
>>> 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
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>>
>>> _______________________________________________
>>> Isis-wg mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>> _______________________________________________
>>> Isis-wg mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>>
>>>
>>> _______________________________________________
>>> Isis-wg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/isis-wg