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

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

Shane -

I am not arguing syntax. My point is that using Reverse Metric TLV one
has to make a configuration change (whether one command or two) on a
router which:

a)Temporarily changes the metric advertised by the local router
b)Temporarily generates the Reverse Metric TLV requesting the peer to
also change the metric it advertsies.

That said, I am guilty of poor exposition - which is perhaps why Tony
and I were not able to reach agreement. Let me provide a revised summary
of the differences between the available solutions:

P2P
---

Without Reverse Metric TLV: Must temporarily alter metric configuration
on both neighbors

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

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

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

The multi-access case is identical to the P2P case with the following
exceptions:

a)The two ISs impacted are the IS which is entering maintenance mode and
the DIS
b)The DIS change affects the metric advertised in pseudo-node LSPs
c)In the case where the entire LAN is to enter maintenance mode only the
DIS is impacted.

On a LAN, I was assuming the two cases of interest were to either take
one neighbor "out of service" or to take the entire LAN out of service.
In the former, the operation is identical to the P2P case except that
what is changed are the cost of reaching the pseudo-node from the
neighbor going into maintenance mode and the cost of the pseudo-node to
that neighbor as advertised in the pseudo-node LSP. If one wants to take
multiple neighbors out of service then it requires multiple "P2P
operations".

In the special case where one wants to put the entire LAN into
maintenance mode, there is no need to alter the cost advertised to the
pseudo-node - one can simply alter the cost of the pseudo-node to all
nodes.

Note also that - as discussed in draft-shen-isis-oper-enhance - if it is
considered onerous to find the DIS, one can avoid that issue by
temporarily altering DIS priority so that the node which you want to
enter maintenance mode also becomes the DIS.

What we agree on is the need for a new tool (advertise non-zero cost in
pseudo-node LSPs) to assist in making LAN maintenance easier (albeit
this has some risks as you have highlighted in your survey). 

What we don't agree on is that the convenience of being able to go to
Node A and issue command(s) which make the necessary temporary config
changes (as opposed to going to Node A and B) justifies the introduction
of the Reverse Metric TLV and its associated complexities.

   Les

> -----Original Message-----
> From: Shane Amante [mailto:[e-mail]]
> Sent: Monday, December 06, 2010 7:53 AM
> To: Les Ginsberg (ginsberg)
> Cc: isis mailing list
> Subject: Re: [Isis-wg] draft-amante-isis-reverse-metric-01
> 
> Les,
> 
> Thanks for your feedback.  I'm rewinding this thread a bit, because I
> disagree with your summary below.
> 
> See below.
> 
> On Dec 5, 2010, at 23:30 MST, Les Ginsberg (ginsberg) wrote:
> > 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?
> 
> In summary, no.  :-)  The goal of this draft is that there is a
> _single_ configuration change required, on just one router, which
would
> simultaneously add/increase the metric to both:
> a)  the local router's interface; and,
> b)  the remote router's interface facing the local router.
> 
> This is discussed, (but perhaps not clearly enough), in:
> 1)  Section 3.5, Operational Guidelines, where we state that IS-IS
> routers MUST NOT modify their existing IS-IS metric, (thus the
> configuration of Reverse Metric is _adding_ to what's already there):
> ---snip---
>    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 stored (e.g.: hard disk, etc.) configurations, since those
>    parameters are carefully derived from off-line capacity planning
>    tools and are difficult to restore to their original values.
> ---snip---
> 2)  Section 4, "Reverse Metric TLV Use Case".  Although this is a non-
> normative section, it hopefully expresses what is expected when the
> Reverse Metric is used in a network and seems fairly clear that only a
> single configuration change (to add the reverse-metric cfg) is
> occurring.
> 
> Does that satisfy your concerns?  If not, can you suggest text that
> would make this more clear?
> 
> Thanks,
> 
> -shane
> 
> 
> 
> >   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