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

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 5 Jan 2018 00:47:32 +0000

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.

Regards,
- Naiming

On Dec 30, 2017, at 4:05 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, December 30, 2017 3:34 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Les,

31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> написал(а):

Alex -

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, December 30, 2017 3:06 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Les,

31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> написал(а):

Alex -

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, December 30, 2017 2:38 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> написал(а):

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:[email-masked]] On Behalf Of Naiming Shen (naiming)
Sent: Saturday, December 30, 2017 11:59 AM
To: Alexander Okonnikov <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Naiming,

29 дек. 2017 г., в 6:10, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> написал(а):

Hi Alexander,

Thanks for the comments, see more replies inline.

On Dec 14, 2017, at 9:24 AM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]>> 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 completed.

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) <[email-masked]<mailto:[email-masked]>> 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:[email-masked]] On Behalf Of Christian Hopps
Sent: 16 November 2017 04:13
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Sat, 6 Jan 2018 00:31:16 +0000

Hi Tom,

Thanks for the review, some replies inline,

On Dec 29, 2017, at 2:53 AM, t.petch <[email-masked]<mailto:[email-masked]>> wrote:

A couple of IANA thoughts on this I-D;

"This document requests that IANA allocate from the IS-IS TLV
  Codepoints Registry a new TLV, "

- Is there a particular range that this value should come from?

NS> will add the range.

- A note in s.2 asking that TBD be replaced by the value that IANA
allocates might be useful for the RFC Editor.

NS> will do.

- Are the flag bits of this new TLV going to form a new registry?

NS> it is not.

- And a non-IANA thought - what does a receiver do if it receives more
than one such TLV?

NS> In section 2, it mentions "A sender MUST only transmit a single
     Reverse Metric TLV in a IS-IS Hello PDU.”

"This document also request that IANA allocate from the link-attribute
  bit value for sub-TLV 19 of TLV 22."
I struggled to parse this initially.

Perhaps
"This document also requests that IANA allocate a bit from the
'link-attribute bit values for sub-TLV 19 of TLV 22' registry.

NS> OK.

(That registry title is a bit of a mouthful compounded by the lack of
Capitals in the title:-(

The coupling between the request to IANA to allocate the bit and the
actual definition in the body of the I-D is ... well, non-existent.  You
should have a something about the octet with a TBD2 (not a second TBD)
in section 3.6, a TBD2 in the IANA actions and a request that this be
replaced by RFC Editor by the value that IANA allocates.

NS> will do.

thanks.
- Naiming

Yes, a reader can deduce all this but the lack of precision is how
mistakes are made IMO.  RFC5209 has the sort of detail that I would
expect.

Tom Petch

----- Original Message -----
From: "Naiming Shen (naiming)" <[email-masked]<mailto:[email-masked]>>

---

From: "t.petch" <[email-masked]>
Date: Sat, 6 Jan 2018 12:12:14 -0000

Naiming

One follow-up comment inline

Tom Petch

---- Original Message -----
From: "Naiming Shen (naiming)" <[email-masked]>
Sent: Saturday, January 06, 2018 12:31 AM

> On Dec 29, 2017, at 2:53 AM, t.petch
>      Reverse Metric TLV in a IS-IS Hello PDU.”

I know it does, but I also know that we cannot rely on all
implementations being perfect:-)

Look at some other RFC (e.g. RFC5029) and you will find an action
defined such as subsequent ones will be ignored, or perhaps that this
should be treated as a fatal error or ..  I suggest something similar
here although have no strong views what the action should be.

Tom Petch

> From: "Naiming Shen (naiming)"
<[email-masked]<mailto:[email-masked]>>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Sat, 6 Jan 2018 19:39:38 +0000

Tom,

Sure. We can add similar wording on that.

thanks.
- Naiming

> On Jan 6, 2018, at 4:12 AM, t.petch <[email-masked]> wrote:
> 
> Naiming
>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Sun, 7 Jan 2018 05:22:04 +0000

Tom,

Actually RFC 5029 does not mention anything about handling
multiple same link-attribute sub-TLV, it just says if a router does not support
this sub-TLV, it will silently ignore the sub-TLV, and this is true
for any IS-IS TLV or sub-TLV. If one does not understand, it has
to ignore it. Spiting out an error or debug message or not is up
to the implementation.

thanks.
- Naiming

> On Jan 6, 2018, at 11:39 AM, Naiming Shen (naiming) <[email-masked]> wrote:
> 
> 
> Tom,
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 7 Jan 2018 14:54:35 +0000

Naiming -

I think what Tom is referring to is this text from RFC 5029:

" This sub-TLV is OPTIONAL and MUST appear at most once for a single IS
   neighbor.  If a received Link State Packet (LSP) contains more than
   one Link-Attribute Sub-TLV, an implementation SHOULD decide to
   consider only the first encountered instance."

In the case of the Reverse Metric TLV, since it is only allowed in hellos, it would be easy to specify a similar behavior.
The other alternative is to say when multiple such TLVs are received they are all ignored.
I don't have a strong opinion either way - but I am inclined to the "ignore" strategy since if multiple TLVs are sent it seems clear that the receiver cannot tell what the sender intends. Given this is being used to modify the running config on the receiver, it seems more prudent NOT to do anything unless the instructions are unambiguous.

   Les

> Sent: Saturday, January 06, 2018 9:22 PM
> To: t.petch <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; [email-masked]; isis-
> [email-masked]
> Actually RFC 5029 does not mention anything about handling multiple same
> link-attribute sub-TLV, it just says if a router does not support this sub-TLV, it
> will silently ignore the sub-TLV, and this is true for any IS-IS TLV or sub-TLV. If
> one does not understand, it has to ignore it. Spiting out an error or debug
> message or not is up to the implementation.
> 
> thanks.
> - Naiming
> 
> >>> - And a non-IANA thought - what does a receiver do if it receives
> >>> more than one such TLV?
> >>>
> >>> "This document also request that IANA allocate from the
> >>> link-attribute bit value for sub-TLV 19 of TLV 22."
> >>> (That registry title is a bit of a mouthful compounded by the lack
> >>> of Capitals in the title:-(
> >>>
> >>> should have a something about the octet with a TBD2 (not a second
> >>> TBD) in section 3.6, a TBD2 in the IANA actions and a request that
> >>> this be replaced by RFC Editor by the value that IANA allocates.
> >>>
> >>>
> >>> NS> will do.
> >>>
> >>> thanks.
> >>> - Naiming
> >>>
> [email-masked]

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Sun, 7 Jan 2018 19:58:48 +0000

Les,

Ok, will ‘ignore’:-) thanks.

- Naiming

> On Jan 7, 2018, at 6:54 AM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Naiming -
>

---

From: Christian Hopps <[email-masked]>
Date: Thu, 11 Jan 2018 04:19:59 -0500

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?

Thanks,
Chris.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 11 Jan 2018 12:20:06 -0800

Hi Chris,

> On Jan 11, 2018, at 1:19 AM, Christian Hopps <[email-masked]> wrote:
> 
> 

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 11 Jan 2018 20:45:35 +0000

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

> From: Naiming Shen (naiming)
> Sent: Thursday, January 11, 2018 12:20 PM
> To: Christian Hopps <[email-masked]>
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; isis-
> [email-masked]
> >> 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,
> >
> 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:
> 
> 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'
> 
> 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)
> <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >>
> >>
> >> To: Les Ginsberg (ginsberg)
> >> <[email-masked]<mailto:[email-masked]>>
> >> Cc: Naiming Shen (naiming)
> >> <[email-masked]<mailto:[email-masked]>>;
> >> [email-masked]<mailto:[email-masked]>; Christian Hopps
> >> <[email-masked]<mailto:[email-masked]>>;
> >> [email-masked]<mailto:[email-masked]>
> >> 31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg)
> <[email-masked]<mailto:[email-masked]>> написал(а):
> >>
> >> Alex -
> >>
> >> To: Les Ginsberg (ginsberg)
> >> <[email-masked]<mailto:[email-masked]>>
> >> Cc: Naiming Shen (naiming)
> >> <[email-masked]<mailto:[email-masked]>>;
> >> [email-masked]<mailto:[email-masked]>; Christian Hopps
> >> <[email-masked]<mailto:[email-masked]>>;
> >> [email-masked]<mailto:[email-masked]>
> >> 31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg)
> <[email-masked]<mailto:[email-masked]>> написал(а):
> >>
> >> Alex -
> >>
> >> To: Les Ginsberg (ginsberg)
> >> <[email-masked]<mailto:[email-masked]>>
> >> Cc: Naiming Shen (naiming)
> >> <[email-masked]<mailto:[email-masked]>>;
> >> [email-masked]<mailto:[email-masked]>; Christian Hopps
> >> <[email-masked]<mailto:[email-masked]>>;
> >> [email-masked]<mailto:[email-masked]>
> >> 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:
> >>
> >> [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
> >>
> >>
> >>
> >> [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.
> >> 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)
> <[email-masked]<mailto:[email-masked]>> написал(а):
> >>
> >> 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.
> >> 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
> >>
> >>
> >> To: Alexander Okonnikov
> <[email-masked]<mailto:[email-masked]
> >>
> >> Cc: [email-masked]<mailto:[email-masked]>; Christian Hopps
> >> <[email-masked]<mailto:[email-masked]>>;
> >> [email-masked]<mailto:[email-masked]>
> >> 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
> <[email-masked]<mailto:[email-masked]
> >> wrote:
> >>
> >> Hi Naiming,
> >>
> >>
> >>
> >>
> >>
> >> 29 дек. 2017 г., в 6:10, Naiming Shen (naiming)
> <[email-masked]<mailto:[email-masked]>> написал(а):
> >>
> >>
> >> Hi Alexander,
> >>
> >> On Dec 14, 2017, at 9:24 AM, Alexander Okonnikov
> <[email-masked]<mailto:[email-masked]
> >> wrote:
> >>
> >> Hi authors,
> >>
> >>
> >> 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.
> >>
> >>
> >> 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
> >> 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.
> >>
> >> 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
> >> 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.
> >>
> >> On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant)
> <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >> Hello,
> >>
> >> 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
> >> 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
> >>

---

From: Alexander Okonnikov <[email-masked]>
Date: Tue, 16 Jan 2018 09:21:00 +0300

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) <[email-masked]>, писал:
> > To: Christian Hopps <[email-masked]
> > > > <[email-masked]<mailto:[email-masked]
> > > > [email-masked]<mailto:[email-masked]
> > > > <[email-masked]<mailto:[email-masked]
> > > > [email-masked]<mailto:[email-masked]
> > > > <[email-masked]<mailto:[email-masked]
> > > > [email-masked]<mailto:[email-masked]
> > > > [email-masked]<mailto:[email-masked]
> > > > To: [email-masked]<mailto:[email-masked]
> > > > Cc: [email-masked]<mailto:[email-masked]
> > > > [email-masked]<mailto:[email-masked]
> > > > [email-masked]<mailto:[email-masked]
> > > > [email-masked]<mailto:[email-masked]

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Tue, 16 Jan 2018 06:46:13 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Naiming, Les, Chris,

Thanks.

Best regards,
Alexander Okonnikov

11 янв. 2018 г., 23:45 +0300, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>, писал:
I agree with Naiming on these changes.

Les

-----Original Message-----
From: Naiming Shen (naiming)
Sent: Thursday, January 11, 2018 12:20 PM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; isis-
[email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> writes:

Hi,

Hi Naiming,

thanks.
- Naiming

Thanks,
Chris.

Regards,
- Naiming

On Dec 30, 2017, at 4:05 PM, Les Ginsberg (ginsberg)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, December 30, 2017 3:34 PM
To: Les Ginsberg (ginsberg)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]
Cc: Naiming Shen (naiming)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]
Subject: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-reverse-metric-07

Les,

31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> написал(а):

Alex -

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, December 30, 2017 3:06 PM
To: Les Ginsberg (ginsberg)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]
Cc: Naiming Shen (naiming)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]
Subject: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-reverse-metric-07

Les,

31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> написал(а):

Alex -

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, December 30, 2017 2:38 PM
To: Les Ginsberg (ginsberg)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]
Cc: Naiming Shen (naiming)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]
Subject: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-reverse-metric-07

Hi Les,

Les

Regarding L1 circuit between L1/L2 routers - it is not always possible or is
not desired.

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.

Les

Les

Thank you.

31 дек. 2017 г., в 1:33, Les Ginsberg (ginsberg)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> написал(а):

“a receiver of a

Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of Naiming
Shen (naiming)
Sent: Saturday, December 30, 2017 11:59 AM
To: Alexander Okonnikov

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]

Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]><mailto:[email-masked]
Subject: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-reverse-metric-07

Hi Alex,

thanks.
- Naiming

On Dec 29, 2017, at 11:46 AM, Alexander Okonnikov
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]
wrote:

Hi Naiming,

29 дек. 2017 г., в 6:10, Naiming Shen (naiming)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> написал(а):

Hi Alexander,

On Dec 14, 2017, at 9:24 AM, Alexander Okonnikov
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]
wrote:

Hi authors,

NS> will fix.

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.

NS> agreed. will remove this, to keep the same goal as above, to be
simple. Not to mix them.

NS> To me, there is not much difference between DIS and other nodes.
Will try to add some words to that.

thanks.
- Naiming

Thanks!

Hi Ketan,

On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant)
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Hello,

I support this draft, however would like the following aspect/scenario
clarified.

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.

Thanks,
Ketan

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of
Christian Hopps
Sent: 16 November 2017 04:13
To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]
Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]
Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Thanks,
Chris.

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 18 Jan 2018 12:50:13 +0300

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) пишет:
>> On Jan 15, 2018, at 10:21 PM, Alexander Okonnikov 
>> <[email-masked] 
>> <mailto:[email-masked]>> 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) 
>> <[email-masked] <mailto:[email-masked]>>, писал:
>>> 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.
>>>
>>>> To: Christian Hopps <[email-masked] <mailto:[email-masked]>
>>>> Cc: Les Ginsberg (ginsberg) <[email-masked] 
>>>> <mailto:[email-masked]>>; [email-masked] 
>>>> <mailto:[email-masked]>; isis-
>>>> [email-masked] <mailto:[email-masked]>
>>>> link as
>>>> <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>>;
>>>>>> [email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>>;
>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>>>> <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>> написал(а):
>>>>>>
>>>>>> Alex -
>>>>>>
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>>;
>>>>>> [email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>>;
>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>>>> <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>> написал(а):
>>>>>>
>>>>>> Alex -
>>>>>>
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>>;
>>>>>> [email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>>;
>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>>>> <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>> написал(а):
>>>>>>
>>>> <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]
>>>>>>
>>>>>> Cc: [email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]>>;
>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>>>> <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]
>>>>>> wrote:
>>>>>>
>>>>>> Hi Naiming,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>> написал(а):
>>>>>>
>>>>>>
>>>>>> Hi Alexander,
>>>>>>
>>>> <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]
>>>>>> wrote:
>>>>>>
>>>>>> Hi authors,
>>>>>>
>>>>>>
>>>> <[email-masked] 
>>>> <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> To: [email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]
>>>>>> Cc: [email-masked] 
>>>>>> <mailto:[email-masked]><mailto:[email-masked]
>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>>>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 18 Jan 2018 18:30:28 +0000

Hi Alexander,

As mentioned, the ‘reverse-metric’ is an ‘Offset metric’, and it’s accumulative on the receiving
end. So when you send (2^24-2) over, unless the other side is configured on interface of
IS-IS metric of zero (which is the case on Pnode), then you are not going to deterministically
for the case of (2^24-2) vs (2^24-1) as a result. The ‘U’ bit is for setting that top limit for neighbor.
Thus in the mobility use case, without knowing the other side configured metric, this side
can do ‘1’, ‘2’, ‘etc’ to gradually increase the “inbound” metric towards itself.

If this were an ‘absolute’ value for the other side to install regardless of their configured metric,
then you are right.

thanks.
- Naiming

On Jan 18, 2018, at 1:50 AM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]>> wrote:

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.

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.

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.

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).

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.

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.

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.

Hi Alexander,

thanks.
- Naiming

Hi Naiming, Les, Chris,

Thanks.

Best regards,
Alexander Okonnikov

Les

-----Original Message-----
From: Naiming Shen (naiming)
Sent: Thursday, January 11, 2018 12:20 PM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; isis-

Hi Chris,

Hi,

Hi Naiming,

thanks.
- Naiming

Thanks,
Chris.

Regards,
- Naiming

Les,

Alex -

Les,

Alex -

Hi Les,

Les

Les

Les

Thank you.

“a receiver of a

Les

Hi Alex,

thanks.
- Naiming

Hi Naiming,

Hi Alexander,

Hi authors,

NS> will fix.

thanks.
- Naiming

Thanks!

Hi Ketan,

Hello,

thanks.
- Naiming

Thanks,
Ketan

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

Thanks,
Chris.

---

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 18 Jan 2018 21:35:40 +0300

Hi Naiming,

Yes, my point is that reverse-metric values 2^24-2 and 2^24-1 are special-purpose values for which operation “set” should be applied rather than “add”. For other values (below 2^24-2) operation “add” is performed with the rule ‘min(sum, 2^24-2)’.

Thank you.

Best regards,
Alexander Okonnikov

18 янв. 2018 г., 21:30 +0300, Naiming Shen (naiming) <[email-masked]>, писал:
> > On Jan 18, 2018, at 1:50 AM, Alexander Okonnikov <[email-masked]> wrote:
> >
> > Hi Naiming,
> >
> > > > On Jan 15, 2018, at 10:21 PM, Alexander Okonnikov <[email-masked]> wrote:
> > > >
> > > > Hi Naiming, Les, Chris,
> > > >

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 18 Jan 2018 15:04:21 -0800

Hi Alexander,

That’s true. But we do need to handle when in add operation it can
also come to the acculative number of (2^24-2) or (2^24-1) and which
one to use. So this draft defines normal condition only cap at (2^24-2),
unless specified by ‘U’ bit. This way we are consistent in all the cases.

thanks.
- Naiming

> On Jan 18, 2018, at 10:35 AM, Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Naiming,
> 
> 18 янв. 2018 г., 21:30 +0300, Naiming Shen (naiming) <[email-masked] <mailto:[email-masked]>>, писал:
>> 
>> Hi Alexander,
>> 
>>> On Jan 18, 2018, at 1:50 AM, Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Naiming,
>>> 
>>>>> On Jan 15, 2018, at 10:21 PM, Alexander Okonnikov <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Hi Naiming, Les, Chris,
>>>>> 
>>>>> 11 янв. 2018 г., 23:45 +0300, Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>, писал:
>>>>>>> Cc: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; isis-
>>>>>>>> On Jan 11, 2018, at 1:19 AM, Christian Hopps <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Naiming Shen (naiming) <[email-masked] <mailto:[email-masked]>> writes:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> From: Alexander Okonnikov [mailto:[email-masked] <mailto:[email-masked]>]
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; Christian Hopps
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> написал(а):
>>>>>>>>> 
>>>>>>>>> Alex -
>>>>>>>>> 
>>>>>>>>> From: Alexander Okonnikov [mailto:[email-masked] <mailto:[email-masked]>]
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; Christian Hopps
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> написал(а):
>>>>>>>>> 
>>>>>>>>> Alex -
>>>>>>>>> 
>>>>>>>>> From: Alexander Okonnikov [mailto:[email-masked] <mailto:[email-masked]>]
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; Christian Hopps
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> написал(а):
>>>>>>>>> 
>>>>>>>>> From: Isis-wg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Naiming
>>>>>>>>> Shen (naiming)
>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> 
>>>>>>>>> Cc: [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; Christian Hopps
>>>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Naiming,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> написал(а):
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi Alexander,
>>>>>>>>> 
>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi authors,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hello,
>>>>>>>>> 
>>>>>>>>> From: Isis-wg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of
>>>>>>>>> Christian Hopps
>>>>>>>>> To: [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> Cc: [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/ <https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/>
>>>>>>>>> 
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg <https://www.ietf.org/mailman/listinfo/isis-wg>
>>>>>>>>> 
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg <https://www.ietf.org/mailman/listinfo/isis-wg>
>>>>>>>>> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg <https://www.ietf.org/mailman/listinfo/isis-wg>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg <https://www.ietf.org/mailman/listinfo/isis-wg>
>>>>>> 
>>>>>> https://www.ietf.org/mailman/listinfo/isis-wg <https://www.ietf.org/mailman/listinfo/isis-wg>
>>>> 
>>> 
>>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 24 Jan 2018 06:32:28 -0500

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) <[email-masked]> writes:

>>> 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:
>>>
>>> [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
>>>
>>>
>>>
>>> [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.
>>> 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.
>>>
>>>
>>>
>>>
>>> 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.
>>> 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
>>>
>>>
>>> Naiming Shen (naiming)
>>> <[email-masked]<mailto:[email-masked]>>
>>> <[email-masked]<mailto:[email-masked]>> 
>>> wrote:
>>>
>>> Hi Naiming,
>>>
>>>
>>>
>>>
>>>
>>> <[email-masked]<mailto:[email-masked]>> 
>>> wrote:
>>>
>>> Hi authors,
>>>
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>
>>> 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 
>>> NS> sounds resonable. Will change this to say if the sub-TLV 
>>> of TE is not received, the TE properties will not change
>>> 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!
>>>
>>>
>>> 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?
>>> metric’ over the link,
>>> 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
>>>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 24 Jan 2018 22:56:26 +0000

Hi Chris,

Thanks for the comments, please see replies inline,

> On Jan 24, 2018, at 3:32 AM, Christian Hopps <[email-masked]> wrote:
> 
> 
> 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
>  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.

NS> This is while responding to one of the LC comments, it seemed confusing
to do in the previous way in 07. We made the change in 08 version to have them
go independently. Yes, we missed the M-ISIS section. Good catch.

> 
> - 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?

NS> You are right! Completely agree and will remove this paragraph.

> 
>  - 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)
>  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
>  - There are other reasons to set the reverse metric (e.g., high   BER on
>    receive).

NS> Ok, will change to more general terms.

> 
> - 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

NS> We missed that. Will sync up with the 3.1 and use the new mechanism
across.

> 
> 
> - 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?

NS> makes sense, will do.

thanks
- Naiming

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 25 Jan 2018 05:55:38 +0000

Hi,

the new version uploaded.

please review.
thanks.
- Naiming

On Jan 24, 2018, at 2:56 PM, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Chris,

On Jan 24, 2018, at 3:32 AM, Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:

thanks
- Naiming

Thanks,
Chris.

Hi Chris,

Hi,

Hi Naiming,

thanks.
- Naiming

Thanks,
Chris.

Regards,
- Naiming

On Dec 30, 2017, at 4:05 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, December 30, 2017 3:34 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Les,

31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> написал(а):

Alex -

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, December 30, 2017 3:06 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Les,

31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> написал(а):

Alex -

From: Alexander Okonnikov [mailto:[email-masked]]
Sent: Saturday, December 30, 2017 2:38 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Hi Les,

Les

Les

Les

Thank you.

31 дек. 2017 г., в 1:33, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> написал(а):

“a receiver of a

Les

From: Isis-wg [mailto:[email-masked]] On Behalf Of Naiming Shen (naiming)
Sent: Saturday, December 30, 2017 11:59 AM
To: Alexander Okonnikov <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Hi Alex,

thanks.
- Naiming

On Dec 29, 2017, at 11:46 AM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Hi Naiming,

29 дек. 2017 г., в 6:10, Naiming Shen (naiming) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> написал(а):

Hi Alexander,

On Dec 14, 2017, at 9:24 AM, Alexander Okonnikov <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Hi authors,

NS> will fix.

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.

thanks.
- Naiming

Thanks!

Hi Ketan,

On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Hello,

thanks.
- Naiming

Thanks,
Ketan

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: 16 November 2017 04:13
To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Thu, 25 Jan 2018 07:38:45 -0500

Starting another 2 week WGLC on the latest version (09)

WGLC ends Thursday Feb 8th.

Thanks,
Chris.