Subject: [Isis-wg] Fwd: I-D Action:draft-amante-isis-reverse-metric-00.txt

From: Shane Amante <[email-masked]>
Date: Wed, 13 Oct 2010 20:56:33 -0600

Hi,

Per a discussion on the mailing list last month, spurred by Mikael, here's a first attempt at a proposal to enable the bidirectional changing of an IS-IS link metric in order to gracefully remove a link from the topology during network maintenance events.  Comments are welcome.  

-shane

Begin forwarded message:
> From: [email-masked]
> Date: October 13, 2010 8:45:02 PM MDT
> To: [email-masked]
> Subject: I-D Action:draft-amante-isis-reverse-metric-00.txt 
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : IS-IS Reverse Metric TLV for Network Maintenance Events
> 	Author(s)       : N. Shen, et al.
> 	Filename        : draft-amante-isis-reverse-metric-00.txt
> 	Pages           : 11
> 	Date            : 2010-10-13
> 
> This document describes an improved IS-IS neighbor management scheme
> which can be used to enhance network performance by allowing
> operators to quickly and accurately shift traffic away from a point-
> to-point or multi-access LAN interface by allowing one IS-IS router
> to signal to a second, adjacent IS-IS neighbor to adjust its IS-IS
> metric that should be used to temporarily reach the first IS-IS
> router during network maintenance events.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-amante-isis-reverse-metric-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "iLya" <[email-masked]>
Date: Thu, 14 Oct 2010 13:51:59 +0200

--------------------------------------------------
From: "Shane Amante" <[email-masked]>
Sent: Thursday, October 14, 2010 4:56 AM
To: "isis mailing list" <[email-masked]>
Subject: [Isis-wg] Fwd: I-D Action:draft-amante-isis-reverse-metric-00.txt

> Hi,
>
> Per a discussion on the mailing list last month, spurred by Mikael, here's 
> a first attempt at a proposal to enable the bidirectional changing of an 
> IS-IS link metric in order to gracefully remove a link from the topology 
> during network maintenance events.  Comments are welcome.
>

Shane,

a paragraph in Section 2 reads:

"   The Metric field may be a "default metric", in the range of 0-63, or
   a "Traffic Engineering Default Metric" [RFC5305] "

You've probably ment "Default metric" of TLV 2 or "Default metric" of TLV 22 
(and not TE Default Metric). Additionally, it would be nice to cover IPv6 
metric (RFC5308) if multi-topology is used using sub-TLV as you did for TE 
Metric.

Also, the draft should probably spell out what a receiver should do if it 
receives reverse metric >63 but the node itself is not configured to use TLV 
22 (though I don't know if there are any networks left that still use 
old-style metric).

Kind regards,
iLya

---

From: Shane Amante <[email-masked]>
Date: Thu, 14 Oct 2010 21:55:10 -0600

Hi Ilya,

Thanks for your comments.  See below.

On Oct 14, 2010, at 05:51 MDT, iLya wrote:
> You've probably ment "Default metric" of TLV 2 or "Default metric" of TLV 22 (and not TE Default Metric).

We did.  But, I think we also need to cover sub-TLV 18 (TE Default Metric) within the Extended IS Reachability TLV, since that sub-TLV can also be used by CSPF correct? 

> Additionally, it would be nice to cover IPv6 metric (RFC5308) if multi-topology is used using sub-TLV as you did for TE Metric.

OK.  Will fix.

> Also, the draft should probably spell out what a receiver should do if it receives reverse metric >63 but the node itself is not configured to use TLV 22 (though I don't know if there are any networks left that still use old-style metric).

OK.  Will fix.

Thanks!

-shane

> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Fri, 15 Oct 2010 14:38:57 +0100

Authors,

A few comments.

in section 3. Elements of Procedure,

  A router SHOULD first update its own IS-IS metric and/or Traffic
    Engineering parameters in its IS Neighbors TLV, Extended IS
    Reachability TLV or Pseudonode LSP, then recompute its SPF tree plus
    corresponding route metrics and, lastly, flood its updated LSP's,
    using normal IS-IS mechanisms, as well as start advertising a Reverse
    Metric TLV in IIH's toward a neighbor.

it mandates (here and elsewhere)  that when a reverse metric is 
generated or received the order of operations should be
1. update LSP(s)
2. re-compute own SPF
3. finally flood revised LSP(s)

In the case of an increase in metric this is likely to increase the 
possibility that a temporary micro-loop is generated, since it forces 
the local system to update its forwarding tables before it's upstream 
neighbor. It would be better (in the case of a metric increase) to use 
the order
1. update LSP(s)
2. flood revised LSP(s)
3 re-compute own SPF (and update local FIB)

However, in the case of a metric decrease, the first order would be better.

I would suggest that the actual ordering be left to the implementation 
to determine, rather than recommending a specific ordering  which may be 
pessimal.

It may be the case that the wording used was not intended to be 
interpreted as a temporal ordering, but it is hard not to so interpret 
it. Perhaps a wording that simply states that those actions need to be 
performed without any implied ordering would be better.

Secondly, I'm not sure that we can get away with saying it raises no new 
security concerns, since it provides a vector to manipulate the metrics 
of another system. I agree that this is not particularly serious, since 
there are plenty of other ways for a trusted system to disrupt routing, 
but I think a sentence or two to this effect would be required by the 
security folks.

Thirdly, Is the intention that the reverse metric mechanism should only 
be allowed to increase a metric. i.e. the LSP contains the greater of 
the locally configured value and a value received in the reverse metric 
TLV.?

Finally the para

  The Metric field contains a 24-bit unsigned integer equal to the
    IS-IS metric a neighbor SHOULD set in its own IS Neighbors TLV or
    Extended IS Reachability TLV for point-to-point links, or Pseudonode
    LSP by the Designated Intermediate System (DIS) for multi-access
    LAN's, back toward the router that originated this Reverse Metric
    TLV.  An IS-IS neighbor MUST overwrite the existing IS-IS metric, in
    its corresponding IS Neighbors, Extended IS Reachability TLV or
    Pseudonode LSP, with the value it received in the Metric field of the
    Reverse Metric TLV.

The first SHOULD is confusing, since it is followed by what appears to 
be a MUST for the same thing. Is it simply saying

  The Metric field contains a 24-bit unsigned integer equal to the
    IS-IS metric to be conveyed to a neighbor for setting in its own IS Neighbors TLV

and the sentence

    It is RECOMMENDED that implementations provide a capability to
    disable any changes to a node's default metric or Traffic Engineering
    parameters based upon receipt of properly formatted Reverse Metric
    TLV's.

I assume this simply means that it is recommended to provide a facility 
to ignore a received reverse metric TLV. If so, why not say so? If not, 
could you explain in more detail what it DOES mean? If the former, how 
does this match with the other statements that it MUST respond?

     Mike

-- 
For corporate legal information go to:
www.cisco.com/web/about/doing_business/legal/cri

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 15 Oct 2010 09:05:40 -0700

I have previously stated my opposition to using the protocol in this way
- but I hope the authors will still entertain comments from me despite
this. :-)

It seems that the draft proposes - in addition to the reverse metric -
that the TLV can carry any of the subTLVs defined for TLVs 22/222. This
is not fully explained e.g. it should be mentioned in the IANA section
as it affects the codepoint registry. But more importantly it makes the
scope of the TLV much more than "reverse-metric" - it seems that you are
defining a generic way to override protocol circuit configuration on the
neighbor. This makes me wonder on what basis we can restrict what
attributes are allowed to be specified in this TLV. For example, given
what you have already included, why should the following also not be
allowed:

  LAN priority
  Hello timer
  Hello Multiplier
  LSP Throttle Interval
  LSP Retransmit Interval
  Etc.

???

I am not advocating this (of course) - but given that the draft
introduces the ability to override local circuit configuration on the
neighbor, I think we need to be clear on where the line will be drawn
(if at all) on what can be set in this way and what cannot.

The draft also mentions that implementations SHOULD provide a way to
block the use of the overrides. I can envision something like:

   isis metric 20 ignore-override 

(YSMV)

But what about cases in which the configuration is set by a network
management tool e.g. an SNMP set? Does this imply that the IS-IS MIB
(RFC 4444) needs to be extended so that the "ignore-override" semantic
can be set for the various circuit attributes? I would think so.

  Les