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

[Alexander Okonnikov]

Hi Naiming,

For signaling unreachability of the link to ISs outside that link we 
don't need utilize U-bit in IIH. When receiving IS observes that IGP or 
TE reverse metric is 2^24-1, it sets its operational forward metric to 
2^24-1 as well and signals it in its LSP, without redundant signaling 
via U-bit in received IIH. As a consequence, other ISs become aware 
about unreachability of the link (in fact about unreachability of the 
link for IGP and TE topologies). This is the same I proposed to do 
without U-bit. One detail about U-bit I am confused is that U-bit 
signals that both metrics (IGP and TE) should be maximized, 
irrespectively to values of metrics in Offset field and in TE Default 
Metric Sub-TLV (the latter may not be present at all).

This is not needed to allocate new bit to signal that metric value must 
not exceed 2^24-1. Values of both kinds of metric are signaled using 
24-bit fields in LSP, so it is not possible to advertise values greater 
than 2^24-1. If sum of forward + reverse metric is greater than 2^24-1, 
it should be set by receiver to 2^24-1, like it is being done for 'last 
resort' mode, described in section 3.1, where metric value must not be 
greater than 2^24-2.

Follow is my proposal in examples without U-bit:

1. Originator wishes to make link last resort for IGP, but not TE:

Originator sets Metric Offset value to 2^24-2. TE reverse metric is not 
advertised or advertised with value 0.
Receiver sets its IGP metric to 2^24-2 (even if its IGP forward metric 
is >=1). Receiver's TE metric is not modified.

2. Originator wishes to make link last resort for TE, but not IGP:

Originator sets TE reverse metric to 2^24-2. Metric Offset value is 0.
Receiver sets its TE metric to 2^24-2 (even if its TE forward metric is 
>=1). Receiver's IGP metric is not modified.

3. Originator wishes to make link last resort for both IGP and TE:

Originator sets Metric Offset and TE metric values to 2^24-2.
Receiver sets its IGP and TE metrics to 2^24-2 (even if its IGP and TE 
forward metrics are >=1).

4. Originator wishes to make link unreachable for IGP, but not TE:

Originator sets Metric Offset value to 2^24-1. TE reverse metric is not 
advertised or advertised with value 0.
Receiver sets its IGP metric to 2^24-1 (irrespectively to its IGP 
forward metric). Receiver's TE metric is not modified.

5. Originator wishes to make link unreachable for TE, but not IGP:

Originator sets TE reverse metric to 2^24-1. Metric Offset value is 0.
Receiver sets its TE metric to 2^24-1 (irrespectively to its TE forward 
metric). Receiver's IGP metric is not modified.

6. Originator wishes to make link unreachable for both IGP and TE:

Originator sets Metric Offset and TE metric values to 2^24-1.
Receiver sets its IGP and TE metrics to 2^24-1 (irrespectively to its 
IGP and TE forward metrics).

Thank you.


16.01.2018 09:46, Naiming Shen (naiming) пишет:

Hi Alexander,

The reason we share that ‘U' bit, first of all, this is a bit on the 
link, not in LSP,
unless the LSP propagates the meaning, no one outside knows about that.
So, it is important to have the neighbor to raise the metric for both 
IGP and TE
to indicate something for both metric.
2nd, the ‘U’-bit just indicate the max can be upto 2^24-1. if the 
accumulated
metric of configured plus the ‘reverse’ is >= 2^24-1. If one wants to have
one is usable and the other is unusable, that is easy, send in 
‘reverse-metric' TLV
for the normal metric to be zero, and the ‘reverse-metric’ TE sub-TLV 
metric
to be ‘2^24-1’, that will achevie exact the effect, and set the ‘U’ bit.
The other way around is also the same.

thanks.
- Naiming

On Jan 15, 2018, at 10:21 PM, Alexander Okonnikov 
<alexander.okonni...@gmail.com 
<mailto:alexander.okonni...@gmail.com>> wrote:

Hi Naiming, Les, Chris,

Version -08 specifies new U-bit to be used simultaneously both for 
IGP and TE metrics. It seems to be suboptimal. What if the goal is to 
modify IGP link properties while left TE link properties intact? 
U-bit set says that both - IGP and TE metrics - should be maximized 
on receiving IS. From CSPF perspective there is no much difference 
between TE metrics 2^24-2 and 2^24-1 - they are both indicate ‘last 
resort’ but still ‘usable’ link. For TE metric manipulation we have 
reverse TE Default Metric Sub-TLV and don’t need U-bit. For making 
IGP link unusable we have special reverse-metric value 2^24-1 and 
don’t need U-bit as well. If the draft will state that TE metric 
2^24-1 should indicate TE link as unusable (from CSPF perspective), 
reverse TE metric 2^24-1 could be specified as special value for this 
like it is specified for IGP link.

Thanks.

Best regards,
Alexander Okonnikov

11 янв. 2018 г., 23:45 +0300, Les Ginsberg (ginsberg) 
<ginsb...@cisco.com <mailto:ginsb...@cisco.com>>, писал:
I agree with Naiming on these changes.

Originally I was opposed to the use of max_metric-1 by reverse 
metric as with the new bit defined in link attributes there was no 
need. But Naiming has pointed out that in order for the new link 
attribute bit to be effective all routers have to be upgraded to 
support it. His proposal of being able to optionally set 
max_metric-1 means that even routers who do not support 
reverse_metric will avoid the link in question simply because they 
will respond to the large advertised metric at both ends of the link.

Allowing max_metric-1 means the link can be completely removed from 
the IGP topology in both directions in a backwards compatible way.
While max_metric-1 is NOT defined as "do not use" for the TE 
topology, it does make the link very unattractive to any C-SPF which 
considers metric - and so achieves what is desired - again in a 
backwards compatible way.

I think this is a significant improvement.

Many thanks to Naiming for realizing all of the downsides of using 
the new link attribute bit.

Les


-----Original Message-----
From: Naiming Shen (naiming)
Sent: Thursday, January 11, 2018 12:20 PM
To: Christian Hopps <cho...@chopps.org <mailto:cho...@chopps.org>
Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com 
<mailto:ginsb...@cisco.com>>; isis-wg@ietf.org 
<mailto:isis-wg@ietf.org>; isis-
a...@ietf.org <mailto:a...@ietf.org>
Subject: Re: [Isis-wg] WG Last Call for 
draft-ietf-isis-reverse-metric-07


Hi Chris,

On Jan 11, 2018, at 1:19 AM, Christian Hopps <cho...@chopps.org 
<mailto:cho...@chopps.org>> wrote:


Naiming Shen (naiming) <naim...@cisco.com 
<mailto:naim...@cisco.com>> 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)
<ginsb...@cisco.com 
<mailto:ginsb...@cisco.com><mailto:ginsb...@cisco.com>> wrote:



From: Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
Sent: Saturday, December 30, 2017 3:34 PM
To: Les Ginsberg (ginsberg)
<ginsb...@cisco.com 
<mailto:ginsb...@cisco.com><mailto:ginsb...@cisco.com
Cc: Naiming Shen (naiming)
<naim...@cisco.com 
<mailto:naim...@cisco.com><mailto:naim...@cisco.com>>;
isis-wg@ietf.org 
<mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org>; Christian Hopps
<cho...@chopps.org 
<mailto:cho...@chopps.org><mailto:cho...@chopps.org>>;
isis-...@ietf.org <mailto:isis-...@ietf.org><mailto:isis-...@ietf.org
Subject: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-reverse-metric-07

Les,


31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg)
<ginsb...@cisco.com 
<mailto:ginsb...@cisco.com><mailto:ginsb...@cisco.com>> написал(а):

Alex -

From: Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
Sent: Saturday, December 30, 2017 3:06 PM
To: Les Ginsberg (ginsberg)
<ginsb...@cisco.com 
<mailto:ginsb...@cisco.com><mailto:ginsb...@cisco.com
Cc: Naiming Shen (naiming)
<naim...@cisco.com 
<mailto:naim...@cisco.com><mailto:naim...@cisco.com>>;
isis-wg@ietf.org 
<mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org>; Christian Hopps
<cho...@chopps.org 
<mailto:cho...@chopps.org><mailto:cho...@chopps.org>>;
isis-...@ietf.org <mailto:isis-...@ietf.org><mailto:isis-...@ietf.org
Subject: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-reverse-metric-07

Les,



31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg)
<ginsb...@cisco.com 
<mailto:ginsb...@cisco.com><mailto:ginsb...@cisco.com>> написал(а):

Alex -

From: Alexander Okonnikov [mailto:alexander.okonni...@gmail.com]
Sent: Saturday, December 30, 2017 2:38 PM
To: Les Ginsberg (ginsberg)
<ginsb...@cisco.com 
<mailto:ginsb...@cisco.com><mailto:ginsb...@cisco.com
Cc: Naiming Shen (naiming)
<naim...@cisco.com 
<mailto:naim...@cisco.com><mailto:naim...@cisco.com>>;
isis-wg@ietf.org 
<mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org>; Christian Hopps
<cho...@chopps.org 
<mailto:cho...@chopps.org><mailto:cho...@chopps.org>>;
isis-...@ietf.org <mailto:isis-...@ietf.org><mailto:isis-...@ietf.org
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)
<ginsb...@cisco.com 
<mailto:ginsb...@cisco.com><mailto:ginsb...@cisco.com>> написал(а):

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:isis-wg-boun...@ietf.org] On Behalf Of Naiming
Shen (naiming)
Sent: Saturday, December 30, 2017 11:59 AM
To: Alexander Okonnikov

<alexander.okonni...@gmail.com 
<mailto:alexander.okonni...@gmail.com><mailto:alexander.okonni...@gmail.com

Cc: isis-wg@ietf.org 
<mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org>; Christian Hopps
<cho...@chopps.org 
<mailto:cho...@chopps.org><mailto:cho...@chopps.org>>;
isis-...@ietf.org <mailto:isis-...@ietf.org><mailto:isis-...@ietf.org
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
<alexander.okonni...@gmail.com 
<mailto:alexander.okonni...@gmail.com><mailto:alexander.okonni...@gmail.com
wrote:

Hi Naiming,





29 дек. 2017 г., в 6:10, Naiming Shen (naiming)
<naim...@cisco.com 
<mailto:naim...@cisco.com><mailto:naim...@cisco.com>> написал(а):


Hi Alexander,

Thanks for the comments, see more replies inline.





On Dec 14, 2017, at 9:24 AM, Alexander Okonnikov
<alexander.okonni...@gmail.com 
<mailto:alexander.okonni...@gmail.com><mailto:alexander.okonni...@gmail.com
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
NS> 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
NS> 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)
<ket...@cisco.com 
<mailto:ket...@cisco.com><mailto:ket...@cisco.com>> 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:isis-wg-boun...@ietf.org] On Behalf Of
Christian Hopps
Sent: 16 November 2017 04:13
To: isis-wg@ietf.org 
<mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org
Cc: isis-...@ietf.org 
<mailto:isis-...@ietf.org><mailto:isis-...@ietf.org
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
Isis-wg@ietf.org <mailto:Isis-wg@ietf.org><mailto:Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org <mailto:Isis-wg@ietf.org><mailto:Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org <mailto:Isis-wg@ietf.org><mailto:Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org <mailto:Isis-wg@ietf.org>
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org <mailto:Isis-wg@ietf.org>
https://www.ietf.org/mailman/listinfo/isis-wg


_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg