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

From: Shane Amante <[email-masked]>
Date: Mon, 29 Nov 2010 22:54:45 -0700

Hi Mike,

Apologies for the long delay in responding.

On Oct 15, 2010, at 07:38 MDT, mike shand wrote:
> in section 3. Elements of Procedure,

[...]

> 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.

You're interpretation is correct, (that the wording was not intended to be interpreted as a temporal ordering).  I've changed the text to (hopefully) reflect no implied ordering.  Please review Section 3.4 in the -01 version of the draft that should be published momentarily.

> 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.

OK.  I've added a few sentences to the Security Considerations section to reflect the concerns you pointed out.

> 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.?

That was the intention in the -00 version of the draft.  However, after discussion amongst the co-authors we're now proposing, in -01, that the metric sent in a Reverse Metric TLV strictly be _additive_ to the existing configured metric at the receiver.  In general, this will hopefully make for cleaner processing at the receiver.

> 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 intent of the SHOULD was an attempt to indicate that a receiver may have disabled receipt or processing of the Reverse Metric TLV.  Thus, a receiver is not guaranteed (MUST) to add a metric received in a Reverse Metric TLV.  If that still doesn't agree with you, can you propose alternate text that would resolve your concern?

> 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?

You are correct that the above was intended to say that devices should provide a facility to ignore a received reverse-metric TLV.  I had thought the above text was fairly clear, but if it's not can you propose text that would resolve your concern?

Thanks for your comments!

-shane

>    Mike
> 
> 
> On 14/10/2010 03:56, Shane Amante wrote:
>> 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
>>> 
>>> 
>>> _______________________________________________
>>> Isis-wg mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/isis-wg
> 
> -- 
> For corporate legal information go to:
> www.cisco.com/web/about/doing_business/legal/cri
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Shane Amante <[email-masked]>
Date: Mon, 29 Nov 2010 23:13:07 -0700

Les,

On Oct 15, 2010, at 10:05 MDT, Les Ginsberg (ginsberg) wrote:
> 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.

In the -01 version of the draft, which should be published momentarily, we have attempted to make it more clear that this draft is proposing to only alter the default-metric of a receiver and that use of other sub-TLV's in the Reverse Metric TLV is outside the scope of this document.  Since this draft is intended to only enable operators to temporarily "isolate" a link/LAN from the network, altering the receiver's default-metric should be sufficient to meet that need in most/all cases.

> 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.

It is not the intent to make permanent "protocol circuit configuration" changes to a neighbor, as should be clear by the whole of Section 1 in the draft.  The sole intent of this draft is to temporarily, accurately and quickly remove a link/LAN from service in order to "safely" perform intrusive testing & diagnose on that link/LAN, without disrupting existing customer traffic, before restoring that link/LAN back to service.

> 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.
> 
> ???

From a network operator's PoV, it would be silly :-) to consider making temporary changes to the above attributes from a [single] remote neighbor, (which is the scope of the Reverse Metric TLV draft).  Changes to the attributes you mention are never taken lightly by an operator and if/when an operator does change them, it should always be directly on the device(s) and, at the appropriate time, written to non-volatile storage, since these changes are typically: a) network-wide; and, b) permanent.

-shane