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

"Naiming Shen (naiming)" <> Thu, 27 April 2017 01:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C35B126CF9; Wed, 26 Apr 2017 18:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LAkoUHhRq_kk; Wed, 26 Apr 2017 18:47:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B05012441E; Wed, 26 Apr 2017 18:47:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=35462; q=dns/txt; s=iport; t=1493257620; x=1494467220; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zpSjMIqg95ESTL6uWd0U7HnGyGJ8OafbdeA6W+Gv0dY=; b=iA5BYCmHWVYd5r761Upi+1EKdJ/H3oNzMlQgB/oCD5qMFJBBiYAr/7ux jVFtC3IkCGLW8ZVTUn9RzC1q4NpxZK93NUzuE6tBH0AHx/WqkAzI18ZTn SMb3xp25W0CQ/b1zJbMKS/wAYtLHxEI/JsG6N9ICOtM4f9M8PjLSpwudB A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.37,256,1488844800"; d="scan'208,217";a="238159695"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2017 01:46:59 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v3R1kxRd028278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2017 01:46:59 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 20:46:58 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 20:46:58 -0500
From: "Naiming Shen (naiming)" <>
To: "Les Ginsberg (ginsberg)" <>
CC: "" <>, "" <>
Thread-Topic: Comments on draft-ietf-isis-reverse-metric-05
Thread-Index: AdK+JxQJA15q8GGGTXq4r5Ic9IlvxQA+vzUA
Date: Thu, 27 Apr 2017 01:46:58 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_72C10D04235B41BA81F3A20D9E1A38A0ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] Comments on draft-ietf-isis-reverse-metric-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Apr 2017 01:47:03 -0000


Thanks for the detailed comments. See some of my replies inline
between [NS->] [<-NS]:

On Apr 25, 2017, at 6:01 PM, Les Ginsberg (ginsberg) <<>> wrote:

Naiming/Michael/Shane -

Some comments on the draft.

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?

I have some points on this:
(1) if the linecard resets on the router, that is not a graceful restart case for IS-IS
(2) related to the comments you were with Mikael on the ‘a matter of seconds’,
      this issue is more with BGP VPN than with IS-IS routes. IS-IS routes can be
      downloaded into the line card quickly, but millions of VPN routes may take
      a while
(3) During this ‘take a while’, we still want to be the last resort of connection
      to our neighbors, instead of just blindly refuse any traffic inbound
(4) Outbound traffic direction may not have any problem, we certainly want
      to reuse the link as soon as possible.

How about we add some text to refer to those reasonings on this use-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?

Yes, you are right if the link is point-to-point. As described in RFC 8042
“OSPF Two-Part Metric”, if the base-station is the DIS, it does not want
to set link metric for all the remote stations, and it could be only one
remote station moves away or closer.

How about we remove the point-to-point circuit in the text of this use-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.

I think we were mainly for future proofing point on this. Sure, will get rid of the S flag.

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.

Agreed. Wll remove this sentence.

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.

Your suggested text (thread with Mikael):
"The use of Reverse Metric does not alter IS-IS metric parameters stored in a router's persistent provisioning database.”
looks good to me.

Regarding the TE related text  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.

Sure, TE can be impacted by ‘color’, link congestion data from inband or out-band,
and many other things. Its hard to cover all the things from SND point of view.

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 .

Ok. But which TE traffic? You can say even if it’s ‘overloaded’ I still want to
send certain TE traffic over. When this side of the link pushes a large
offset value of reverse-metric over and the other side adds this to the
link metric and TE metric values, if the controller wants to detect this
condition (normally the network uses metric below 3000, and this
link suddenly has the value of a billion, I’ll conside the other side of
this link is ‘overloaded’.

I’m just saying I’m not sure if this is a real case. We can certainly
add that if needed.

Best Regards,
- Naiming