Re: [Isis-wg] draft-amante-isis-reverse-metric-01

["Les Ginsberg (ginsberg)" <[e-mail]>]

Shane -

The revised draft is significantly clearer. Thanx.

I am still struggling with the justification for the Reverse Metric TLV.
Let me try to summarize the differences between available solutions to
the problem with/without the Reverse Metric TLV.

Point-Point Circuits
----------------------

Without Reverse Metric TLV: Must change metric configuration on both
neighbors

With Reverse Metric TLV: On one neighbor change the local metric AND
configure the reverse metric to be sent to the other neighbor

The difference is then one config change on two neighbors vs two config
changes on one neighbor.

Multi-Access LANs
-----------------

Without Reverse Metric TLV: On the DIS must configure max metric to be
sent in p-node LSP on the DIS for the neighbor(s) of interest (or ALL
neighbors)

With Reverse Metric: Must configure the reverse metric to be sent to the
DIS on each neighbor of interest - or in the case of impacting ALL
neighbors the reverse metric config an be done on any neighbor (DIS or
non-DIS)

The difference is then whether the config change MUST be done on the DIS
or may be done on any neighbor on the LAN.

Would you agree with this summary?

Frankly, I am not seeing this benefit as very compelling. The big win on
the LAN is the introduction of the ability to use something other than 0
in the pseudo-node LSPs - and that can be done (with the same amount of
risk) without the Reverse Metric TLV by configuring it on the DIS.

   Les


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Shane Amante
> Sent: Monday, November 29, 2010 10:26 PM
> To: isis mailing list
> Subject: [Isis-wg] draft-amante-isis-reverse-metric-01
> 
> Hi Everyone,
> 
> The authors wish to announce a new version of this draft has been
> published.  It is a substantial revision from the -00 version, based
on
> comments received on the list.  Some of the notable, high-level
changes
> are as follows:
> - changed the procedure so that a receiver of a Reverse Metric TLV
> treats the recv'd Metric value as 'additive' to its existing,
> configured default-metric (instead of 'overwriting' its existing,
> configured default-metric);
> - narrowed the scope of the draft to discuss only making changes to a
> neighbor's default-metric;
> - added support for MT-ISIS;
> - added Security Considerations section;
> ... as well as a substantial overall reorganization to hopefully make
> the draft easier to read and follow.
> 
> We welcome your comments and questions.
> 
> Thanks!
> 
> -shane
> 
> ---snip---
> 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-01.txt
> 	Pages           : 13
> 	Date            : 2010-11-29
> 
> 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-
> 01.txt
> ---snip---
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg