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

From: Alexander Okonnikov <[email-masked]>
Date: Thu, 14 Dec 2017 20:24:16 +0300

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.

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.

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 without TE metric Sub-TLV, 
in order to signal that "TE metric is left intact".

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.

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]> 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]
>> Cc: [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]
>> https://www.ietf.org/mailman/listinfo/isis-wg
>>
>> _______________________________________________
>> Isis-wg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/isis-wg
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Fri, 29 Dec 2017 03:10:02 +0000

Hi Alexander,

Thanks for the comments, see more replies inline.

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

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

---

From: "t.petch" <[email-masked]>
Date: Fri, 29 Dec 2017 10:53:33 -0000

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?

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

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

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

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

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

---

From: Alexander Okonnikov <[email-masked]>
Date: Fri, 29 Dec 2017 22:46:07 +0300

Hi Naiming,

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

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.

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Sat, 30 Dec 2017 19:58:56 +0000

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,

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

Hi authors,

NS> will fix.

thanks.
- Naiming

Thanks!

On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant) <[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]>
Cc: [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]
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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 30 Dec 2017 22:33:32 +0000

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

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

Thanks,
Chris.

---

From: Alexander Okonnikov <[email-masked]>
Date: Sun, 31 Dec 2017 01:38:16 +0300

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

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

Thank you.

> 31 дек. 2017 г., в 1:33, Les Ginsberg (ginsberg) <[email-masked]> написал(а):
> 
> From: Isis-wg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Naiming Shen (naiming)
> 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]>
> 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,
> 
> 
> On Nov 28, 2017, at 11:54 PM, Ketan Talaulikar (ketant) <[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]>
> Cc: [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]>
> https://www.ietf.org/mailman/listinfo/isis-wg <https://www.ietf.org/mailman/listinfo/isis-wg>
> 
> [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]>
> https://www.ietf.org/mailman/listinfo/isis-wg <https://www.ietf.org/mailman/listinfo/isis-wg>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 30 Dec 2017 22:48:34 +0000

Alex -

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

Hi Les,

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

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

   Les

Thank you.

31 дек. 2017 г., в 1:33, Les Ginsberg (ginsberg) <[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]>>
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,

thanks.
- Naiming

Hi Naiming,

Hi Alexander,

Hi authors,

NS> will fix.

thanks.
- Naiming

Thanks!

Hi Ketan,

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]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

Thanks,
Chris.

---

From: Alexander Okonnikov <[email-masked]>
Date: Sun, 31 Dec 2017 02:06:28 +0300

Les,

> 31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg) <[email-masked]> написал(а):
> 
> Alex -
>  
> From: Alexander Okonnikov [mailto:[email-masked] <mailto:[email-masked]>] 
> 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]>
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.
> 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. 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
>  
> Thank you.
> 
> 
> 31 дек. 2017 г., в 1:33, Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>> написал(а):
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 30 Dec 2017 23:25:52 +0000

Alex -

Sent: Saturday, December 30, 2017 3:06 PM

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,

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

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.

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

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

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

Thanks,
Chris.

---

From: Alexander Okonnikov <[email-masked]>
Date: Sun, 31 Dec 2017 02:34:03 +0300

Les,

> 31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg) <[email-masked]> написал(а):
> 
> Alex -
>  
> 31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>> написал(а):
>  
> Alex -
>  
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:] 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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 31 Dec 2017 00:05:54 +0000

Sent: Saturday, December 30, 2017 3:34 PM

Les,

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

Alex -

Les,

Alex -

Hi Les,

[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

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

Thanks,
Chris.