Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
Alexander Okonnikov <alexander.okonnikov@gmail.com> Thu, 18 January 2018 09:50 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 6152912EB2C; Thu, 18 Jan 2018 01:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.301
X-Spam-Level: **
X-Spam-Status: No, score=2.301 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, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 PqdIv2U-An4f; Thu, 18 Jan 2018 01:50:19 -0800 (PST)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 029CB12EB2D; Thu, 18 Jan 2018 01:50:18 -0800 (PST)
Received: by mail-lf0-x22a.google.com with SMTP id t79so10414395lfe.3; Thu, 18 Jan 2018 01:50:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=PaqBon0QubIsORxIi+veIW8o+Y+1Nc95odY5Dab6ijQ=; b=kgyMn97RFqhAMVE3p8BgPF1bwF+eq6k7oCNKnWH2x4rXvs926Kdv33LQC/uQhlp2pM nU34AgrMku5C0gvPry56kfN3D79MnsMmlcAVsY9dp/IBto6jdgarfZhhlXe/JRCxZGx+ Ir7pRSSdhycnju7aFFMgEfnfLLrOhK5rI1182wYGryGVClKqUPSGzGNPbNYKr+OSfjVk m2ru7PNPjJloRbGMPO0EB2I8EIcE1M3BrATW6r+zVz2ZCbz7R/ls4S4FMwbuzZQ8Z8jv L2VaI8XUcLEfqY67gTwN6MFgKTvOnvH/mH50PX2OYykEsjlIJPJ8dhC2rrmTA+OYEBRW ++rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=PaqBon0QubIsORxIi+veIW8o+Y+1Nc95odY5Dab6ijQ=; b=OcdUxD6dzAy+tZxPhnGeBvcK1YdfWXxh++d9K2hQua1SneKw/mMPSH00rXLAiCQdw3 Dixdu15M9Yc8RMxs9rGVeaL5xyE2+dSp5IJDdvAoHTYSWa95nyzZZx502Ecns2H55AcX U+J19577ZPo1S3ahEOSOJw5jb5DZxQzubiJLGYbGwg4ARHnNyWjILVUCcRq106SYcr3P eMbRJm1Mreur83In4rLj5nZipG4gVkeev4YNMMZSy5DiKx7ZwAv89+GjPOixiFIq2Yre 40tTc3JxqIT1+qcsyWFV3cfTdKo44BHX7wJIDWir43hTBzaheZ9hW2hHezMzhpF397yV A3cw==
X-Gm-Message-State: AKwxytcWuDtF7mvgsF6zAwaej3sTkuOkwI1JgWtAsI2fjePzVnFUuyAG S2jcyeZDfmkSp1rdRkl2gluzpH0J
X-Google-Smtp-Source: ACJfBou2C+QE51eXfM4lK25CVetT9bto5rlYWeGD2Dbg6qEvbIGYMyk44lgYBU1LMtX+3LKw2fU54w==
X-Received: by 10.46.16.11 with SMTP id j11mr2986498lje.139.1516269015753; Thu, 18 Jan 2018 01:50:15 -0800 (PST)
Received: from [217.195.72.188] (secretmaker-188.ip.PeterStar.net. [217.195.72.188]) by smtp.gmail.com with ESMTPSA id h75sm1218213ljf.36.2018.01.18.01.50.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jan 2018 01:50:14 -0800 (PST)
To: "Naiming Shen (naiming)" <naiming@cisco.com>
Cc: Christian Hopps <chopps@chopps.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, "isis-ads@ietf.org" <isis-ads@ietf.org>
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> <DD26DBC2-BFA7-4EFB-B43A-048DABF3CF8A@gmail.com> <DB2AF030-53B0-4566-BF77-D1CE161406D4@cisco.com> <aea70a9bbb0c453c8f49a838b6cfc961@XCH-ALN-001.cisco.com> <B966787C-A028-4439-ACE3-2FB7B7F44AAC@gmail.com> <cb1e0ebb9e44454e900a56ad4a7b59d9@XCH-ALN-001.cisco.com> <2F941D6B-0F3F-482F-A6A6-31153FA6D311@gmail.com> <b9a735f4afba41d4be28eff333d6bb1b@XCH-ALN-001.cisco.com> <4E92E297-A6CA-4635-A60D-362C0AD864D7@gmail.com> <69982e54510942eeb3523d5a7de63fa6@XCH-ALN-001.cisco.com> <1A958D80-C689-447A-96ED-5AA365F2AF14@cisco.com> <87a7xk7nwg.fsf@chopps.org> <63627BFC-62F7-479D-B2EF-C6A7453CE6C5@cisco.com> <eea946106eeb4917a3c1ce780dfd0460@XCH-ALN-001.cisco.com> <e330d5b5-e049-4399-983e-b0cdcceccf0a@Spark> <BB25AEDE-3329-4B42-AF23-0C0C3956CE39@cisco.com>
From: Alexander Okonnikov <alexander.okonnikov@gmail.com>
Message-ID: <cf21dccb-9648-8982-eb1d-b41bd8d92c42@gmail.com>
Date: Thu, 18 Jan 2018 12:50:13 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <BB25AEDE-3329-4B42-AF23-0C0C3956CE39@cisco.com>
Content-Type: multipart/alternative; boundary="------------5F1DB17C46750B9B6C39D02E"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/VWx2gYYFYRbC3ZQ6wFKHx2ACGos>
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: Thu, 18 Jan 2018 09:50:31 -0000
Hi Naiming, For signaling unreachability of the link to ISs outside that link we don't need utilize U-bit in IIH. When receiving IS observes that IGP or TE reverse metric is 2^24-1, it sets its operational forward metric to 2^24-1 as well and signals it in its LSP, without redundant signaling via U-bit in received IIH. As a consequence, other ISs become aware about unreachability of the link (in fact about unreachability of the link for IGP and TE topologies). This is the same I proposed to do without U-bit. One detail about U-bit I am confused is that U-bit signals that both metrics (IGP and TE) should be maximized, irrespectively to values of metrics in Offset field and in TE Default Metric Sub-TLV (the latter may not be present at all). This is not needed to allocate new bit to signal that metric value must not exceed 2^24-1. Values of both kinds of metric are signaled using 24-bit fields in LSP, so it is not possible to advertise values greater than 2^24-1. If sum of forward + reverse metric is greater than 2^24-1, it should be set by receiver to 2^24-1, like it is being done for 'last resort' mode, described in section 3.1, where metric value must not be greater than 2^24-2. Follow is my proposal in examples without U-bit: 1. Originator wishes to make link last resort for IGP, but not TE: Originator sets Metric Offset value to 2^24-2. TE reverse metric is not advertised or advertised with value 0. Receiver sets its IGP metric to 2^24-2 (even if its IGP forward metric is >=1). Receiver's TE metric is not modified. 2. Originator wishes to make link last resort for TE, but not IGP: Originator sets TE reverse metric to 2^24-2. Metric Offset value is 0. Receiver sets its TE metric to 2^24-2 (even if its TE forward metric is >=1). Receiver's IGP metric is not modified. 3. Originator wishes to make link last resort for both IGP and TE: Originator sets Metric Offset and TE metric values to 2^24-2. Receiver sets its IGP and TE metrics to 2^24-2 (even if its IGP and TE forward metrics are >=1). 4. Originator wishes to make link unreachable for IGP, but not TE: Originator sets Metric Offset value to 2^24-1. TE reverse metric is not advertised or advertised with value 0. Receiver sets its IGP metric to 2^24-1 (irrespectively to its IGP forward metric). Receiver's TE metric is not modified. 5. Originator wishes to make link unreachable for TE, but not IGP: Originator sets TE reverse metric to 2^24-1. Metric Offset value is 0. Receiver sets its TE metric to 2^24-1 (irrespectively to its TE forward metric). Receiver's IGP metric is not modified. 6. Originator wishes to make link unreachable for both IGP and TE: Originator sets Metric Offset and TE metric values to 2^24-1. Receiver sets its IGP and TE metrics to 2^24-1 (irrespectively to its IGP and TE forward metrics). Thank you. 16.01.2018 09:46, Naiming Shen (naiming) пишет: > > Hi Alexander, > > The reason we share that ‘U' bit, first of all, this is a bit on the > link, not in LSP, > unless the LSP propagates the meaning, no one outside knows about that. > So, it is important to have the neighbor to raise the metric for both > IGP and TE > to indicate something for both metric. > 2nd, the ‘U’-bit just indicate the max can be upto 2^24-1. if the > accumulated > metric of configured plus the ‘reverse’ is >= 2^24-1. If one wants to have > one is usable and the other is unusable, that is easy, send in > ‘reverse-metric' TLV > for the normal metric to be zero, and the ‘reverse-metric’ TE sub-TLV > metric > to be ‘2^24-1’, that will achevie exact the effect, and set the ‘U’ bit. > The other way around is also the same. > > thanks. > - Naiming > >> On Jan 15, 2018, at 10:21 PM, Alexander Okonnikov >> <alexander.okonnikov@gmail.com >> <mailto:alexander.okonnikov@gmail.com>> wrote: >> >> Hi Naiming, Les, Chris, >> >> Version -08 specifies new U-bit to be used simultaneously both for >> IGP and TE metrics. It seems to be suboptimal. What if the goal is to >> modify IGP link properties while left TE link properties intact? >> U-bit set says that both - IGP and TE metrics - should be maximized >> on receiving IS. From CSPF perspective there is no much difference >> between TE metrics 2^24-2 and 2^24-1 - they are both indicate ‘last >> resort’ but still ‘usable’ link. For TE metric manipulation we have >> reverse TE Default Metric Sub-TLV and don’t need U-bit. For making >> IGP link unusable we have special reverse-metric value 2^24-1 and >> don’t need U-bit as well. If the draft will state that TE metric >> 2^24-1 should indicate TE link as unusable (from CSPF perspective), >> reverse TE metric 2^24-1 could be specified as special value for this >> like it is specified for IGP link. >> >> Thanks. >> >> Best regards, >> Alexander Okonnikov >> >> 11 янв. 2018 г., 23:45 +0300, Les Ginsberg (ginsberg) >> <ginsberg@cisco.com <mailto:ginsberg@cisco.com>>, писал: >>> I agree with Naiming on these changes. >>> >>> Originally I was opposed to the use of max_metric-1 by reverse >>> metric as with the new bit defined in link attributes there was no >>> need. But Naiming has pointed out that in order for the new link >>> attribute bit to be effective all routers have to be upgraded to >>> support it. His proposal of being able to optionally set >>> max_metric-1 means that even routers who do not support >>> reverse_metric will avoid the link in question simply because they >>> will respond to the large advertised metric at both ends of the link. >>> >>> Allowing max_metric-1 means the link can be completely removed from >>> the IGP topology in both directions in a backwards compatible way. >>> While max_metric-1 is NOT defined as "do not use" for the TE >>> topology, it does make the link very unattractive to any C-SPF which >>> considers metric - and so achieves what is desired - again in a >>> backwards compatible way. >>> >>> I think this is a significant improvement. >>> >>> Many thanks to Naiming for realizing all of the downsides of using >>> the new link attribute bit. >>> >>> Les >>> >>> >>>> -----Original Message----- >>>> From: Naiming Shen (naiming) >>>> Sent: Thursday, January 11, 2018 12:20 PM >>>> To: Christian Hopps <chopps@chopps.org <mailto:chopps@chopps.org> >>>> Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com >>>> <mailto:ginsberg@cisco.com>>; isis-wg@ietf.org >>>> <mailto:isis-wg@ietf.org>; isis- >>>> ads@ietf.org <mailto:ads@ietf.org> >>>> Subject: Re: [Isis-wg] WG Last Call for >>>> draft-ietf-isis-reverse-metric-07 >>>> >>>> >>>> Hi Chris, >>>> >>>>> On Jan 11, 2018, at 1:19 AM, Christian Hopps <chopps@chopps.org >>>>> <mailto:chopps@chopps.org>> wrote: >>>>> >>>>> >>>>> Naiming Shen (naiming) <naiming@cisco.com >>>>> <mailto:naiming@cisco.com>> writes: >>>>> >>>>>> Hi, >>>>>> >>>>>> Sounds reasonable. At this stage of the draft, we’ll probably skip >>>>>> this capability. If it is found needed later, it can be added easily. >>>>>> I suspect there are a number of other things can be later ride on >>>>>> top of >>>> this. >>>>> >>>>> Hi Naiming, >>>>> >>>>> Correct me if I'm wrong, but aren't you saying here that you would not >>>>> add the 2^24-1 functionality? I'm asking b/c you also just published a >>>>> new version -08 that appears to add this functionality. :) >>>>> >>>>> Was there any off-list discussion that led to the change of heart? >>>> >>>> Actually, this is not really a new functionality of the draft:-) We >>>> also removed >>>> the section 3.6 “Link Overload Attribute Bit” of sub-TLV of TLV 22 >>>> in the LSP. >>>> This change is due to several factors: >>>> >>>> - the long discusion ongoing of OSPF mailing list of the name >>>> “overload”, >>>> which has disagreement on what does this “overload” really meant, and >>>> what to do if it’s “overloaded”. This version 7 borrowed this from >>>> OSPF, and >>>> now we got requests also to reconsider the name of this “Link Overload >>>> Attribute Bit” >>>> >>>> - More importantly we just realized that, to use this “overload” >>>> bit in LSP, the >>>> backwards compatibility is not possible anymore, as in the other >>>> “reverse- >>>> metric” feature which is all local to the link. So, if we have to >>>> use this >>>> “overload” bit in LSP, we have also to define the router >>>> “capabilities” to >>>> advertise this, and synchronize among area/domain, which we really >>>> don’t >>>> want to do in ‘reverse-metric' >>>> >>>> - Third with this “U” bit, it achieves the same effect of the >>>> “overload” bit, >>>> since the neighbor can optionally set the (2^24-1) and take out the >>>> link as >>>> ‘unusable’ for IGP or TE, while at the mean time keep the same >>>> backwards >>>> compatibility in the area/domain, which is a very clean solution. >>>> >>>> - I have had long email/chat discussion on this with Les, since we >>>> have seen >>>> the email, this (2^24-1) has been part of the comments discussion >>>> during the >>>> last call. and at the time I didn’t think clearly and mentioned on >>>> the list we >>>> wouldn't do that, but with all the above mentioned reasons, we >>>> decided that >>>> is the right way to go. As mentioned, the reason of doing that is >>>> not to handle >>>> the multi-area LDP/IGP sync kind of use-case, but to support TE >>>> topology to >>>> take the link out just as in the removed section 3.6 in ver 7. >>>> >>>> thanks. >>>> - Naiming >>>> >>>>> >>>>> Thanks, >>>>> Chris. >>>>> >>>>>> Regards, >>>>>> - Naiming >>>>>> >>>>>> On Dec 30, 2017, at 4:05 PM, Les Ginsberg (ginsberg) >>>> <ginsberg@cisco.com >>>> <mailto:ginsberg@cisco.com><mailto:ginsberg@cisco.com>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> From: Alexander Okonnikov [mailto:alexander.okonnikov@gmail.com] >>>>>> Sent: Saturday, December 30, 2017 3:34 PM >>>>>> To: Les Ginsberg (ginsberg) >>>>>> <ginsberg@cisco.com >>>>>> <mailto:ginsberg@cisco.com><mailto:ginsberg@cisco.com >>>>>> Cc: Naiming Shen (naiming) >>>>>> <naiming@cisco.com >>>>>> <mailto:naiming@cisco.com><mailto:naiming@cisco.com>>; >>>>>> isis-wg@ietf.org >>>>>> <mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org>; Christian Hopps >>>>>> <chopps@chopps.org >>>>>> <mailto:chopps@chopps.org><mailto:chopps@chopps.org>>; >>>>>> isis-ads@ietf.org <mailto:isis-ads@ietf.org><mailto:isis-ads@ietf.org >>>>>> Subject: Re: [Isis-wg] WG Last Call for >>>>>> draft-ietf-isis-reverse-metric-07 >>>>>> >>>>>> Les, >>>>>> >>>>>> >>>>>> 31 дек. 2017 г., в 2:25, Les Ginsberg (ginsberg) >>>> <ginsberg@cisco.com >>>> <mailto:ginsberg@cisco.com><mailto:ginsberg@cisco.com>> написал(а): >>>>>> >>>>>> Alex - >>>>>> >>>>>> From: Alexander Okonnikov [mailto:alexander.okonnikov@gmail.com] >>>>>> Sent: Saturday, December 30, 2017 3:06 PM >>>>>> To: Les Ginsberg (ginsberg) >>>>>> <ginsberg@cisco.com >>>>>> <mailto:ginsberg@cisco.com><mailto:ginsberg@cisco.com >>>>>> Cc: Naiming Shen (naiming) >>>>>> <naiming@cisco.com >>>>>> <mailto:naiming@cisco.com><mailto:naiming@cisco.com>>; >>>>>> isis-wg@ietf.org >>>>>> <mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org>; Christian Hopps >>>>>> <chopps@chopps.org >>>>>> <mailto:chopps@chopps.org><mailto:chopps@chopps.org>>; >>>>>> isis-ads@ietf.org <mailto:isis-ads@ietf.org><mailto:isis-ads@ietf.org >>>>>> Subject: Re: [Isis-wg] WG Last Call for >>>>>> draft-ietf-isis-reverse-metric-07 >>>>>> >>>>>> Les, >>>>>> >>>>>> >>>>>> >>>>>> 31 дек. 2017 г., в 1:48, Les Ginsberg (ginsberg) >>>> <ginsberg@cisco.com >>>> <mailto:ginsberg@cisco.com><mailto:ginsberg@cisco.com>> написал(а): >>>>>> >>>>>> Alex - >>>>>> >>>>>> From: Alexander Okonnikov [mailto:alexander.okonnikov@gmail.com] >>>>>> Sent: Saturday, December 30, 2017 2:38 PM >>>>>> To: Les Ginsberg (ginsberg) >>>>>> <ginsberg@cisco.com >>>>>> <mailto:ginsberg@cisco.com><mailto:ginsberg@cisco.com >>>>>> Cc: Naiming Shen (naiming) >>>>>> <naiming@cisco.com >>>>>> <mailto:naiming@cisco.com><mailto:naiming@cisco.com>>; >>>>>> isis-wg@ietf.org >>>>>> <mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org>; Christian Hopps >>>>>> <chopps@chopps.org >>>>>> <mailto:chopps@chopps.org><mailto:chopps@chopps.org>>; >>>>>> isis-ads@ietf.org <mailto:isis-ads@ietf.org><mailto:isis-ads@ietf.org >>>>>> Subject: Re: [Isis-wg] WG Last Call for >>>>>> draft-ietf-isis-reverse-metric-07 >>>>>> >>>>>> Hi Les, >>>>>> >>>>>> Don't advertise link and advertise it with metric 2^24-1 makes >>>>>> sense again. >>>> In the former case that link cannot be used for TE LSPs, while in >>>> latter one it is >>>> possible. This is also described in RFC 5305: >>>>>> >>>>>> " If a link is advertised with the maximum link metric (2^24 - >>>>>> 1), this >>>>>> link MUST NOT be considered during the normal SPF computation. This >>>>>> will allow advertisement of a link for purposes other than building >>>>>> the normal Shortest Path Tree. An example is a link that is >>>>>> available for traffic engineering, but not for hop-by-hop routing." >>>>>> >>>>>> [Les:] I am well aware of this. My comment regarding (2^24 - 1) >>>>>> is in the >>>> context of reverse metric. If the reason that you want to advertise >>>> (2^24-1) is >>>> because the link is only supposed to be used for TE purposes then >>>> this would >>>> already have been done by the neighbor as part of their >>>> configuration – and >>>> it has nothing to do with adjacency bringup. >>>>>> Idea was to temporarily disable IP forwarding on the link while >>>>>> preserve >>>> ability to use link for other transport. An example when we need it >>>> - IGP-LDP >>>> sync. If you configure 2^24-1 on the neighbor, then link will be >>>> excluded from >>>> IP topology permanently. Also, it is not clear for me how it could >>>> be done on >>>> LAN. >>>>>> >>>>>> >>>>>> [Les:] My point is – if you do not want the link to be used at >>>>>> all – even if >>>> only while waiting for LDP sync to complete – then you simply don’t >>>> advertise >>>> the adjacency. In the case of the LAN you don’t advertise the >>>> adjacency to >>>> the DIS – so there is no 2-way connectivity on that circuit and no >>>> traffic flows >>>> to/from the node via the interface in question. It does not matter >>>> what the >>>> neighbor/DIS is advertising. >>>>>> My point - to have ability to exclude link from IP topology, but >>>>>> still use it in >>>> other topologies. This could be done by advertising metric 2^24-1. If >>>> adjacency is not advertised, then that link is excluded from all >>>> topologies, not >>>> only from IP. In general my proposal is to make reverse-metric >>>> functionality >>>> as flexible as possible and to don't restrict it deliberately. >>>>>> >>>>>> [Les:] This is exactly what I object to. Reverse-metric is not >>>>>> and should not >>>> be a general purpose mechanism to have one node override the >>>> configuration of its neighbors for any and all possible reasons. It >>>> has well >>>> defined use cases which the draft describes and its use should be >>>> limited to >>>> those cases. >>>>>> >>>>>> The additional use cases you have suggested can already be handled by >>>> existing mechanisms which are local to each node and that should >>>> always be >>>> the preferred means. The potential for chaos that results when each >>>> node >>>> utilizes this mechanism to adjust the SPF outcome on other routers >>>> based on >>>> its local view of the current state of convergence is not something >>>> I want to >>>> embrace. >>>>>> >>>>>> Les >>>>>> >>>>>> >>>>>> >>>>>> Regarding L1 circuit between L1/L2 routers - it is not always >>>>>> possible or is >>>> not desired. >>>>>> >>>>>> [Les:] I was covering the example you provided. It was clear from >>>>>> your >>>> example that although L2 only was enabled between the L1/L2 >>>> routers, you >>>> were allowing intra-area traffic to flow over that link. >>>>>> If you do not want intra-area traffic to flow over that link at >>>>>> all, then you >>>> need to insure that L1 destinations are not leaked into L2 – in >>>> which case the >>>> proposed change you are suggesting for reverse-metric would not help. >>>>>> >>>>>> If you think you have a different example that justifies your >>>>>> proposal I >>>> would be happy to review it – but the one you have come up with isn’t >>>> compelling. >>>>>> Two L1/L2 routers could be geographically dispersed. >>>>>> [Les:] Only if the L1/L2 routers are in different areas – in >>>>>> which case your >>>> example does not apply. >>>>>> Not necessary. There could be area represented by sub-ring physical >>>> topology. >>>>>> >>>>>> >>>>>> There could be L2 subdomain which provides L2 path between them. But >>>> sometimes it is not optimal to configure L1/L2 on all transit L2 >>>> routers >>>> between two ones. Also, for redundancy you will need to provide >>>> alternative >>>> L1 path in the core (to avoid routing traffic via access). >>>>>> >>>>>> Another case, when having looped L1 is not desired - when R3 has >>>> reachability to the network via two ABRs (R1 and R2), and R2 is >>>> closer to R3 >>>> than R1 to R3. In case link (path) from R3 to R2 is broken, it is >>>> more optimal >>>> from data path perspective to reroute traffic to R1 rather than to >>>> R2 via R1. It >>>> is not case for regular IP routing, but becomes sensitive when we >>>> have deal >>>> with L2VPN services, such that MS-PW or H-VPLS, where R1 and R2 are >>>> S-PEs >>>> or Hub PEs, respectively. >>>>>> >>>>>> [Les:] We are not discussing all possible network topologies. The >>>>>> topic >>>> here is the Reverse-Metric draft and whether there is a use case >>>> for a node >>>> to tell its neighbor to advertise max-metric (2^24-1). >>>>>> Please stay on topic. If you have an example that justifies your >>>>>> proposal I >>>> would like to hear it – but please stay focused on this use case. >>>>>> >>>>>> Les >>>>>> >>>>>> >>>>>> >>>>>> Les >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 31 дек. 2017 г., в 1:33, Les Ginsberg (ginsberg) >>>> <ginsberg@cisco.com >>>> <mailto:ginsberg@cisco.com><mailto:ginsberg@cisco.com>> написал(а): >>>>>> >>>>>> I strongly disagree with this proposed change. >>>>>> >>>>>> If you want to take the link totally out of the topology then >>>>>> simply don’t >>>> advertise the adjacency. This works for both P2P and LAN cases. >>>>>> This is why the draft states >>>>>> >>>>>> “a receiver of a >>>>>> Reverse Metric TLV MUST use the numerically smallest value of either >>>>>> the sum of its existing default metric and the Metric Offset value in >>>>>> the Reverse Metric TLV or (2^24 - 2)” >>>>>> >>>>>> There is no use case for (2^24 - 1). >>>>>> >>>>>> As for the L1/L2 example topology that Alex used to justify his >>>>>> proposal, >>>> there is a much better way to prevent the premature use of the L1 >>>> link. That >>>> is to enable L1 on the link between the two L1L2 routers but >>>> configure a >>>> larger metric (e.g. 100000) so that the L1/L2 link will only be >>>> used for L1 traffic >>>> when there is no viable L1 only link. There is no need to use >>>> Reverse-Metric >>>> to do so and I believe this is an inappropriate use of this extension. >>>>>> >>>>>> Les >>>>>> >>>>>> >>>>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Naiming >>>>>> Shen (naiming) >>>>>> Sent: Saturday, December 30, 2017 11:59 AM >>>>>> To: Alexander Okonnikov >>>>>> >>>> <alexander.okonnikov@gmail.com >>>> <mailto:alexander.okonnikov@gmail.com><mailto:alexander.okonnikov@gmail.com >>>>>> >>>>>> Cc: isis-wg@ietf.org >>>>>> <mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org>; Christian Hopps >>>>>> <chopps@chopps.org >>>>>> <mailto:chopps@chopps.org><mailto:chopps@chopps.org>>; >>>>>> isis-ads@ietf.org <mailto:isis-ads@ietf.org><mailto:isis-ads@ietf.org >>>>>> Subject: Re: [Isis-wg] WG Last Call for >>>>>> draft-ietf-isis-reverse-metric-07 >>>>>> >>>>>> >>>>>> Hi Alex, >>>>>> >>>>>> Ok. We’ll add a bit to the flag (the 2nd bit) of the ‘reverse-metric >>>>>> TLV’, to indicate the originator requesting the inbound direction of >>>>>> the link not to be used and the metric should be raised by the >>>>>> peer to >>>> (2^24 - 1) regardless the value of the ‘offset metric’ >>>>>> value in the TLV. >>>>>> >>>>>> thanks. >>>>>> - Naiming >>>>>> >>>>>> On Dec 29, 2017, at 11:46 AM, Alexander Okonnikov >>>> <alexander.okonnikov@gmail.com >>>> <mailto:alexander.okonnikov@gmail.com><mailto:alexander.okonnikov@gmail.com >>>>>> wrote: >>>>>> >>>>>> Hi Naiming, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 29 дек. 2017 г., в 6:10, Naiming Shen (naiming) >>>> <naiming@cisco.com >>>> <mailto:naiming@cisco.com><mailto: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 >>>> <mailto:alexander.okonnikov@gmail.com><mailto: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 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) >>>> <ketant@cisco.com >>>> <mailto:ketant@cisco.com><mailto: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 >>>>>> <mailto:isis-wg@ietf.org><mailto:isis-wg@ietf.org >>>>>> Cc: isis-ads@ietf.org >>>>>> <mailto:isis-ads@ietf.org><mailto: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 <mailto:Isis-wg@ietf.org><mailto:Isis-wg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>>> >>>>>> _______________________________________________ >>>>>> Isis-wg mailing list >>>>>> Isis-wg@ietf.org <mailto:Isis-wg@ietf.org><mailto:Isis-wg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>>> _______________________________________________ >>>>>> Isis-wg mailing list >>>>>> Isis-wg@ietf.org <mailto:Isis-wg@ietf.org><mailto:Isis-wg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Isis-wg mailing list >>>>>> Isis-wg@ietf.org <mailto:Isis-wg@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg@ietf.org <mailto:Isis-wg@ietf.org> >>> https://www.ietf.org/mailman/listinfo/isis-wg >
- [Isis-wg] WG Last Call for draft-ietf-isis-revers… Christian Hopps
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Acee Lindem (acee)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Acee Lindem (acee)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Acee Lindem (acee)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Acee Lindem (acee)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Ketan Talaulikar (ketant)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Alexander Okonnikov
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… t.petch
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Alexander Okonnikov
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Alexander Okonnikov
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Alexander Okonnikov
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Alexander Okonnikov
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… t.petch
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Christian Hopps
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Alexander Okonnikov
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Alexander Okonnikov
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Alexander Okonnikov
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Christian Hopps
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- Re: [Isis-wg] WG Last Call for draft-ietf-isis-re… Naiming Shen (naiming)
- [Isis-wg] WG Last Call for draft-ietf-isis-revers… Christian Hopps