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

Alexander Okonnikov <alexander.okonnikov@gmail.com> Fri, 29 December 2017 19:46 UTC

Return-Path: <alexander.okonnikov@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F31126C89; Fri, 29 Dec 2017 11:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HspRWRoyMvsn; Fri, 29 Dec 2017 11:46:11 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFED1200FC; Fri, 29 Dec 2017 11:46:11 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id j143so3718131lfg.0; Fri, 29 Dec 2017 11:46:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9/1xxCzXMqy91Ff4vAxdkwbo1VSqYJfFZ9slXedWrEw=; b=VB/B9ZwlawLktUjKg/PK7Rcn9SbPNnFHEgpmA2PAEpbFFlgCeSuchKUjW7wiozsW/6 JEL3uQVTPj03O4c8M3PaJPQpD8TQW5+LiI0r051E72myqfFEGyXPTcDjK1+SoysCYWBk XvYXgUFWv59fDzF/LU/xuEBGVSiU5cwzuOjmJDBcxMfM7CYGDzXd4zGQjni4FmymeeNl PHHR0b0QB4T3Y3TxN5417zGuQokcEfpXcKIQojTL7e7rUJ492DOhbllJS9ponpETZs8t rX2DAbMM7OCcZlfohOO9hUFnThN5OHEy3xW4/3NXhMHAG7THUXv94F2GOrlVTLXITrwX ngOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9/1xxCzXMqy91Ff4vAxdkwbo1VSqYJfFZ9slXedWrEw=; b=EOMngHZv4QFJjzdtCBgFykDxyRxIjGK3fHhwZNzT4m+T9ZiEw9nxKDjaKZwNrQa7WH OZ5xgOtZ2cHyfJP8vKI+hX+SAUh4mfi9WesGk728abU3unISJcmWCOSzMgEYPCC+xP/I PYFLH52D8hPV8hKl6IkPtodxq4vchT0Ev1TCvml7FBGf1hAjG+MvIMQWBU1F+CDvszt+ e1quzNseuFmhSR7+FxibRi8A+tMWfKtrLgiNXfZiHoltLZrgUVo2WM5RDd/YfWC5lZni 0QZA4aN5YlFINNN0ZAFsXCTHCafgBabguNcZoTHd/vE5rBwYeWTYXZnSfi7siv3nfUhJ BkKQ==
X-Gm-Message-State: AKGB3mI+S38sEjXfKLrUOzFu5I3sLFw4+HxRBsrY0iKRDcnQimZWbZuq eFlAOVHi3ovMkVntZuBXxAES3Z++3BY=
X-Google-Smtp-Source: ACJfBoulYhHyi2we600JATB2vSijEgnOEvFi//07n4MECodiwsvCvLZl6f97UgwQNYk6qJ7SmsSwdg==
X-Received: by 10.46.64.133 with SMTP id r5mr22490643lje.30.1514576769077; Fri, 29 Dec 2017 11:46:09 -0800 (PST)
Received: from [10.0.1.2] ([88.201.167.193]) by smtp.gmail.com with ESMTPSA id c190sm2272240lfc.81.2017.12.29.11.46.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Dec 2017 11:46:08 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
In-Reply-To: <DDC43BA0-7D70-4D7E-B023-A5C04E8B1B88@cisco.com>
Date: Fri, 29 Dec 2017 22:46:07 +0300
Cc: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Christian Hopps <chopps@chopps.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "isis-ads@ietf.org" <isis-ads@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD26DBC2-BFA7-4EFB-B43A-048DABF3CF8A@gmail.com>
References: <87375fp3hv.fsf@chopps.org> <7185dbc2d3f34b9ea844ddef95b6278c@XCH-ALN-008.cisco.com> <481C1CEE-A8B4-4034-B016-D2673296E96B@cisco.com> <700e8fed-40fc-cb1a-1ae3-f8401f167aae@gmail.com> <DDC43BA0-7D70-4D7E-B023-A5C04E8B1B88@cisco.com>
To: "Naiming Shen (naiming)" <naiming@cisco.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/Z2OnBUcGxc_gLyTrxy6hgQUVf0E>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Dec 2017 19:46:15 -0000

Hi Naiming,

> 29 дек. 2017 г., в 6:10, Naiming Shen (naiming) <naiming@cisco.com> написал(а):
> 
> 
> Hi Alexander,
> 
> Thanks for the comments, see more replies inline.
> 
>> On Dec 14, 2017, at 9:24 AM, Alexander Okonnikov <alexander.okonnikov@gmail.com> wrote:
>> 
>> Hi authors,
>> 
>> 
>> I have some comments below regarding the draft:
>> 
>> 
>> 1) Section 2: "There is currently only two Flag bits defined." Per -07 only one flag is defined. S flag was deprecated since version -06 (implicit signaling of presence of Sub-TLVs is used via "Sub-TLV Len" field non-zero value. Text in the beginning of the chapter 2 about flag S is to be removed as well.
> 
> NS> will fix.
> 
>> 
>> 2) Section 3.1: "In order to ensure that an individual TE link is used as a link of last resort during SPF computation, ..." I guess that you meant regular link rather than TE link.
>> 
>> 3) For the same section: Per my understanding, this section assumes that overloaded link will always be considered as last-resort link. I.e. it cannot be excluded from topology (as link with metric 2^24-1), unless originator of the TLV sets appropriate bit in corresponding Link Attributes Sub-TLV (RFC 5029) AND receiving ISs support that Sub-TLV. As alternative it could be done by allowing for originator to specify reverse metric special value 2^24-1 which would indicate to receivers that the link is to be excluded from topology completely rather than used as last resort. If reverse metric value is between 0 - 2^24-2 then link could be used in path calculation. The same rules for TE metric.
> 
> 
> NS> I don’t see there is much difference between not used or last resort in the use cases we mentioned.
> also, this metric value is an ‘offset metric’ being added on top of the existing local metric. It would not
> be always feasible to make the reverse-metric off by one to mean two completely different operations.

One use case when unusable link vs last resort one makes sense is for IGP-LDP sync. Let's assume we have two-level IS-IS domain. There are three ISs in the domain: R1 and R2 are L1/L2 ISs, and R3 is L1-only. R1 and R2 are connected to each other via L2 circuit, and R3 is connected to R1 and R2 via L1 circuits. The link between R2 and R3 was broken and now is being restored. While adjacency has not been established on failed link, R3 has inter-area route towards R2's loopback. Once adjacency has been established, but LDP session has not yet, R3 and R2 maximize metric (2^24-2) on corresponding link. But now R2 and R3 have routes to each other as L1 intra-area, though with max metric. Because L1 intra-area route wins, R2 and R3 replace inter-area routes to each other by intra-area ones. As a result, LDP LSPs are blackholed. On the other hand, if two routers mark corresponding link as unusable (with metric 2^24-1), they would use inter-area routes until IGP-LDP sync will be 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) <ketant@cisco.com> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> I support this draft, however would like the following aspect/scenario clarified.
>>>> 
>>>> Consider the scenario where both the neighbours on a p2p link initiate the reverse metric procedure (i.e. include the TLV in their hellos concurrently). How are implementations supposed to handle this? Normally the choice of metric conveyed via this TLV is based on a particular condition (which need not just be "overload") on the local router which requires the neighbour to use shift to using the reverse metric supplied. So when both neighbours initiate this process, it would be good to have the specification provide a deterministic behaviour since the reverse metric values provided may conflict in certain "non-overload" conditions. If both routers simply accept the value supplied by their neighbour, it may not achieve the original purpose/design of this triggering this mechanism?
>>> When you say if both sides initiated this ‘reverse metric’, you implied
>>> there is a timing issue with this procedure in the draft.
>>> 
>>> The value of this ‘metric offset’ (or whatever will be called) of this TLV,
>>> is just a number. The draft does not say this number is equal to the
>>> configured ‘metric’ value plus the received ‘reverse metrc’ value, that
>>> would be non-deterministic and both sides would keep going up until it’s
>>> overloaded:-)
>>> 
>>> Each side of IS-IS link decides if it needs to send a ‘reverse metric’ over the link,
>>> either in link-overloading case, or other cases. It’s a static number, it does not
>>> depend on the other side sending a ‘reverse metric’ or not. This both sides
>>> sending a ‘reverse-metric’ over a link is equivalent to an operator provisions
>>> new metric (say both plus 10 to the old metric) on both sides of the link at
>>> the same time, there is no non-determinitic thing in this.
>>> 
>>> thanks.
>>> - Naiming
>>> 
>>>> Following options come to my mind:
>>>> a) when this condition is detected, none of the routers actually apply the reverse metric procedure
>>>> b) when this condition is detected, the router with higher/lower system-id value (or some such tiebreaker) wins and the other withdraws its reverse metric (until then (a) applies)
>>>> c) some mechanism/rule that is based on the value of metric offset specified perhaps (made harder since the actual metric is not signalled but the offset) which determines the "winner" so the other withdraws their TLV.
>>>> 
>>>> Since the mechanism is not specific to overload conditions (where this is not an issue), it may be necessary for the specification to clarify this behaviour to ensure interoperability.
>>>> 
>>>> Thanks,
>>>> Ketan
>>>> 
>>>> -----Original Message-----
>>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Christian Hopps
>>>> Sent: 16 November 2017 04:13
>>>> To: isis-wg@ietf.org
>>>> Cc: isis-ads@ietf.org
>>>> Subject: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
>>>> 
>>>> 
>>>> The authors have asked for and we are starting a WG Last Call on
>>>> 
>>>> https://datatracker.ietf.org/doc/draft-ietf-isis-reverse-metric/
>>>> 
>>>> which will last an extended 3 weeks to allow for IETF100.
>>>> 
>>>> Thanks,
>>>> Chris.
>>>> 
>>>> _______________________________________________
>>>> Isis-wg mailing list
>>>> Isis-wg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>>> 
>>>> _______________________________________________
>>>> Isis-wg mailing list
>>>> Isis-wg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/isis-wg
>>> _______________________________________________
>>> Isis-wg mailing list
>>> Isis-wg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/isis-wg
>> 
>