Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05

Mikael Abrahamsson <swmike@swm.pp.se> Wed, 26 April 2017 05:25 UTC

Return-Path: <swmike@swm.pp.se>
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 4C7F3120326; Tue, 25 Apr 2017 22:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 KEMjfWO8bW1G; Tue, 25 Apr 2017 22:25:32 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C50120046; Tue, 25 Apr 2017 22:25:29 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 17C26A4; Wed, 26 Apr 2017 07:25:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1493184326; bh=JK/imgn9Jw8ZbYU75r5ICnoON1lg2WLL0JwjP7Ea7Gw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=nnGr4NVvUWnI709UosqUzz1dQfojEi3Bb20qxz1m2Zavqnpn+zgab+SpTV91tDUjw 5sfDkN2ouixztBT9Mp32X/3NY3j+H2upqP/aauBOd4CY9c+VqY1ZT/gNGswXQ7Bl5v GIQFWvQXXbbFWedEV14OFnjRKD0IeL2qIcmSiQng=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F34DDA3; Wed, 26 Apr 2017 07:25:25 +0200 (CEST)
Date: Wed, 26 Apr 2017 07:25:25 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-isis-reverse-metric.authors@ietf.org" <draft-ietf-isis-reverse-metric.authors@ietf.org>
In-Reply-To: <f6c2518144e64aa8af7d66db894f9dde@XCH-ALN-001.cisco.com>
Message-ID: <alpine.DEB.2.02.1704260724040.5591@uplift.swm.pp.se>
References: <f6c2518144e64aa8af7d66db894f9dde@XCH-ALN-001.cisco.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-221121891-1493184325=:5591"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/c42rjDmmi1gqHH5S6POpPCK-Pvg>
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05
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: Wed, 26 Apr 2017 05:25:34 -0000

Hi,

Thanks for the review!

Regarding 3.5. I think the point here is that when the device received a 
reverse metric offset request, it should not reflect this in the 
persistent configuration storage. The operational metric change is 
ephemeral (I think this is the correct term), not a persistent storage 
change. So the idea here is that there should be no “automatic” update of 
the “running-config” metric setting, just because one is sending or 
receiving a metric-offset TLV. This should be a separate configuration 
item.

Regarding not advertising adjacency at all. Personally, I like to be able 
to take links into a state of “don’t use this unless you absolutely have 
to”. Stopping advertising it at all, takes away that possibility. If I 
have two redundant links to somewhere, one has bit errors, this is 
automatically detected and that link is now “metric:ed up” so it’s not 
used. If the second link goes down, I’d rather send traffic over this 
bit-errored link, than to lose connectivity at all. So if this was a g.709 
forward-error-correction (FEC) covered link, I can configure the router to 
metric-up the link at a certain FEC corrected-errors rate, so that I don’t 
get post-FEC errors. This doesn’t mean the link is unusable as an 
emergency backup if it’s the only one left, it just means I want to avoid 
using it.

Does the draft need text to better explain this?

On Wed, 26 Apr 2017, Les Ginsberg (ginsberg) wrote:

> Section 1.2.  Distributed Forwarding Planes
>
>
>
> RFC 5306 (Restart Signaling) has already defined use of the SA bit in the Restart TLV to request that  a neighbor suppress advertisement of the adjacency thus preventing 2-way connectivity check from passing on that link. It is not clear to me why SA bit is not sufficient.
>
> For that matter, the local system could simply not advertise the adjacency to the neighbor and achieve the same result. Why do we need any extension to handle the adjacency bringup case?
>
>
>
> Section 1.3 Mobility Cases
>
>
>
> I am not clear on why both ISs in such a case would not detect the change in proximity and both do metric adjustment. What is the need for use of reverse metric in this case?
>
>
>
>
>
> Section 2
>
>
>
>> From the description what is being advertised in the new TLV is not a metric but a metric offset i.e. you want the receiving IS to add the advertised value to its existing configured metric. Identifying the metric field as "metric offset" would make this point more clearly.
>
>
>
> In regards to the use of sub-TLVs, I think the only use case you have is to advertise a TE metric offset - but this could easily be done as an additional fixed field in the TLV itself. Unless you foresee other sub-TLVs I think sub-TLVs could be eliminated from the TLV definition. (I also think advertising TE metric offset is unnecessary - see additional comments on TE below)
>
>
>
> If  you want to retain sub-TLVs for future proofing you do not need both an S flag indicating the presence of sub-TLVs and a sub-TLV length field. One or the other will suffice.
>
>
>
>
>
> Last Paragraph of Section 3.1 states:
>
>
>
> "If the router does not understand the Reverse Metric TLV..."
>
>
>
> I don't think this needs to be said. It is standard IS-IS behavior to silently ignore TLVs which are not understood - and if a router does not understand the new TLV it certainly would not know what it is it "should not do". :-)
>
>
>
> The point about allowing local policy to disable processing of the Reverse Metric TLV is a good one and the security reasons for it should be emphasized.
>
>
>
>
>
> Section 3.5
>
>
>
> "During the period when a Reverse Metric TLV is used, IS-IS routers
>
>   that are generating and receiving a Reverse Metric TLV MUST NOT
>
>   change their existing IS-IS metric or Traffic Engineering parameters
>
>   in their persistent provisioning database"
>
>
>
> I would expect that use of Reverse Metric would often be associated with a maintenance window - in which case this is precisely the time to expect configuration changes. Because traffic has been diverted from the link this is actually the safest time to make configuration changes. Therefore I think this restriction is both unnecessary and undesirable.
>
>
>
> Regarding the TE related text
>
>
>
> https://www.ietf.org/id/draft-ietf-ospf-link-overload-06.txt  has highlighted that TE CSPF may not always be based on metric (IGP or TE). In which case altering the metric advertisement may not be sufficient to move TE traffic away from the link.
>
>
>
> I think a more robust strategy would be to assign a bit in the link attributes sub-TLV defined in RFC 5029 to indicate that the state of the link is "maintenance" (or "overload") and that TE traffic should avoid this. That would be more robust than altering TE metric and would also eliminate the need to use the reverse metric to alter TE metric. Please see https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22 .
>
>
>
>   Les
>
>
>
>
>

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se