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

[Alexander Okonnikov <[e-mail]>]

Hi Naiming,

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

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

Follow is my proposal in examples without U-bit:

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

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

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

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

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

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

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

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

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

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

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

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

Thank you.


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