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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 5 Dec 2010 22:30:16 -0800

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: [email-masked] [mailto:[email-masked]] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Tony Li <[email-masked]>
Date: Sun, 5 Dec 2010 23:40:32 -0800

Hi Les,

> Multi-Access LANs

In fact, without the reverse metric TLV, you cannot do this at all.  Without extending the protocol is _some_ way, you are not allowed to have a non-zero metric in the pseudonode.  Further, Shane's survey suggests that there is sufficient variation in implementations that it is unsafe to advertise a non-zero pseudonode metric without some flag day for the domain anyway.

> risk) without the Reverse Metric TLV by configuring it on the DIS.

The ability to make one link of an L2 switching domain into a link of last resort seems like it is compelling to me, and the ability to do so from the system itself seems like a significant simplification for operations.  One less thing to go wrong when the operator doesn't can't fumble finger the manually entered system ID.  Or applies the configuration to a system other than the DIS.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 5 Dec 2010 23:59:20 -0800

Tony -

> From: Tony Li [mailto:[email-masked]]
> Sent: Sunday, December 05, 2010 11:41 PM
> To: Les Ginsberg (ginsberg)
> Cc: Shane Amante; isis mailing list
> Subject: Re: [Isis-wg] draft-amante-isis-reverse-metric-01
> 
> 
> Hi Les,
> 
> > Multi-Access LANs
> > -----------------
> >
> In fact, without the reverse metric TLV, you cannot do this at all.
> Without extending the protocol is _some_ way, you are not allowed to
> have a non-zero metric in the pseudonode.  Further, Shane's survey
> suggests that there is sufficient variation in implementations that it
> is unsafe to advertise a non-zero pseudonode metric without some flag
> day for the domain anyway.

The "extension" is - as you say - the use of non-zero metric in the
pseudonode LSP. This does not, however, imply that we need the Reverse
Metric TLV. It is a question of how you signal the DIS to advertise the
non-zero metric. That can be done by local configuration on the DIS.
This is discussed in  draft-shen-isis-oper-enhance - and there it is
pointed out that one can temporarily make any given the node the DIS by
changing LAN priority - so if finding the DIS is the onerous task this
can be worked around.

Everything you want to do can be done without the Reverse Metric TLV -
and the risks are the same. However this is signaled (local config or
Reverse Metric TLV) so long as the DIS supports the new functionality,
it is possible to start advertising non-zero metrics in pseudo-node LSPs
without knowing whether all ISs in the domain support this extension or
not.

The ability to override local configuration via information advertised
by your neighbor introduces a management application capability into the
routing protocol itself - and also introduces additional complexities.
These complexities include handling competing advertisements from
multiple neighbors and supporting configuration to block the use of
reverse metric TLV - both of which are discussed in the draft. If we
never introduce the Reverse Metric TLV we can still do everything that
is required and we do not have to introduce a new TLV nor deal with
these problematic cases.

I think draft-shen-isis-oper-enhance is quite sufficient and there is no
need for the Reverse Metric TLV.

   Les

> 
> 
> > Frankly, I am not seeing this benefit as very compelling. The big
win
> The ability to make one link of an L2 switching domain into a link of
> last resort seems like it is compelling to me, and the ability to do
so
> from the system itself seems like a significant simplification for
> operations.  One less thing to go wrong when the operator doesn't
can't
> fumble finger the manually entered system ID.  Or applies the
> configuration to a system other than the DIS.
> 
> Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 6 Dec 2010 00:30:25 -0800

Les,

Aren't we supposed to be making it easier to operate a network?  It seems like adding 'workarounds' is the wrong direction: you're adding complexity to operations in conjunction with the requested functionality.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 6 Dec 2010 00:44:09 -0800

Tony -

I honestly don't understand your comment below. 
I started this new thread by summarizing how one could achieve the
desired functionality with or without the Reverse Metric TLV.

<snip>

<end snip>

I am not suggesting a "workaround" - I am pointing out that you can use
local config to achieve the same functionality. I am also pointing out
that configuration-wise this is not any more onerous than the
configuration required to specify the use of reverse-metric TLV. I am
also pointing out that using local config avoids:

1)Introduction of new TLV support
2)Requirement to handle competing advertisements from multiple neighbors
3)Requirement to support "block reverse TLV usage" configuration

We are both headed in the same direction i.e. provide a new tool by
supporting non-zero metric in pseudo-node LSPs. The issue that remains
is how to configure support for this. I don't see how what is proposed
in draft-shen-isis-oper-enhance (which I support) is more complex than
reverse metric TLV - in fact I think the opposite is the case.

   Les

> Behalf Of Tony Li
> Sent: Monday, December 06, 2010 12:30 AM
> Aren't we supposed to be making it easier to operate a network?  It
> seems like adding 'workarounds' is the wrong direction: you're adding
> complexity to operations in conjunction with the requested
> functionality.
> 
> Tony
>

---

From: Shane Amante <[email-masked]>
Date: Mon, 6 Dec 2010 08:53:00 -0700

Les,

Thanks for your feedback.  I'm rewinding this thread a bit, because I disagree with your summary below.  

See below.

> the problem with/without the Reverse Metric TLV.

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 6 Dec 2010 08:51:56 -0800

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

> From: Shane Amante [mailto:[email-masked]]
> Sent: Monday, December 06, 2010 7:53 AM
> Cc: isis mailing list
> 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:
> 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---
> 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.
>

---

From: mike shand <[email-masked]>
Date: Mon, 06 Dec 2010 16:57:57 +0000

> The difference is then one config change on two neighbors vs two

But presumably, there is no reason why these two conceptual actions 
could not be triggered by a single CLI command.

Mike

---

From: Shane Amante <[email-masked]>
Date: Mon, 6 Dec 2010 13:21:58 -0700

Les,

> this has some risks as you have highlighted in your survey).

OK.

> of the Reverse Metric TLV and its associated complexities.

With all due respect, it sounds like you may not appreciate the size/class of networks we run today.  :-)  

Over the last several years, we (and other SP's) have been deploying multi-Terabit class routers, (i.e.: no "marketing math" <ahem>).  Each of these have onboard several hundred high-speed interfaces _each_.  You're asserting that it's easier, on a _daily_ basis, for me and other SP's to:
a)  accurately identify the same [point-to-point] interface on two, separate routers (again, w/ hundreds of interfaces apiece) at 3AM in the morning;
b)  remember/write-down the existing IS-IS metric that was configured *before* I begin the maintenance;
c)  change the metric (on both sides) to isolate the link/LAN; and,
d)  back out the above changes, at a similar unholy hour of the morning?

And, we wonder why the Internet is only perceived as a "best-effort" network?

On a more serious note, it's important to recognize that in order to mitigate human-error, we need to reduce the burden on operators to "always get it right", as you seem to imply above, and certainly as our executives (and customers) want us to.  Codifying something like the Reverse Metric TLV in the protocol allows operators to have a _repeatable_, interoperable mechanism that will dramatically reduce the risk of 'human error' for a widely accepted & used operational practice (link isolation).  Given that all public studies I've seen classify 'human error' as the dominant cause of network outages, one would think we should be looking at ways to remedy that ...

-shane

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 06 Dec 2010 21:42:46 +0100

All,

> On a more serious note, it's important to recognize that in order to
> mitigate human-error, we need to reduce the burden on operators to
> "always get it right", as you seem to imply above, and certainly as
> our executives (and customers) want us to.

Watching this thread with deep interest I must say that I am with Les here.

The problem is that this is nearly 2011 and we still do not have a good 
way to configure networks as an entire abstraction. We do at most - in 
sophisticated networks - have scripts to configure routers on a box to 
box basis.

Instead of working on network wide level config tool/protocol we are 
extending protocols to achieve the equivalent functionality. And this is 
not only in ISIS, we do the same in BGP, we do the same in MPLS etc ...

So while I am not seeing any harm with this draft as is I think at some 
point we should put serious effort to look at the network as an 
abstraction layer and configure such abstraction layer rather then 
continue the trend of extending routing protocols to deliver equivalent 
functionality.

That IMHO would be the best way to address the "human error" issue.

Cheers,
R.

---

From: Tony Li <[email-masked]>
Date: Mon, 6 Dec 2010 12:47:51 -0800

Robert,

> Instead of working on network wide level config tool/protocol we are extending protocols to achieve the equivalent functionality. And this is not only in ISIS, we do the same in BGP, we do the same in MPLS etc ...

So, you're suggesting that we stop work on improving protocols until the NMS folks get their act together.

This doesn't seem like a practical suggestion.

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 06 Dec 2010 21:57:19 +0100

Hi Tony,

Actually completely opposite :)

It seems clear to me that this is not NMS thing. They have tried hard 
and failed to deliver right solution for long enough.

I think this is our fault that we are still looking at networks from 
single box perspective as opposed to look at them from domain wide 
perspective (as starter).

So while we are at ISIS WG I would not mind if we would just run a new 
instance purely for network wide config making each router to be an NMS 
station. Call it C-ISIS. Example: instead of configuring links on the 
adjacent nodes configure link parameter anywhere, instead of configuring 
node at a node .. configure it anywhere.

Then we could go higher and start thinking about configuring services.

Many thx,
R.

PS.

/* After all we have many uses for ISIS today ... TRILL included :) */

> Robert,
>
>> Instead of working on network wide level config tool/protocol we
>> are extending protocols to achieve the equivalent functionality.
>> And this is not only in ISIS, we do the same in BGP, we do the same
>> in MPLS etc ...
>
>
> Regards, Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 6 Dec 2010 13:09:29 -0800

> So while we are at ISIS WG I would not mind if we would just run a new instance purely for network wide config making each router to be an NMS station. Call it C-ISIS. Example: instead of configuring links on the adjacent nodes configure link parameter anywhere, instead of configuring node at a node .. configure it anywhere.

Somehow, cramming the NMS into the routing protocol seems like the worst of all worlds.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 6 Dec 2010 13:47:53 -0800

Shane -

> Sent: Monday, December 06, 2010 12:22 PM
> Over the last several years, we (and other SP's) have been deploying
> multi-Terabit class routers, (i.e.: no "marketing math" <ahem>).  Each
> of these have onboard several hundred high-speed interfaces _each_.
> You're asserting that it's easier, on a _daily_ basis, for me and
other
> SP's to:
> a)  accurately identify the same [point-to-point] interface on two,
> separate routers (again, w/ hundreds of interfaces apiece) at 3AM in
> the morning;

I am actually more sympathetic to your concerns than it may appear.

Just because I am pushing for doing this via local config and against
via a protocol extension does not mean that I am against the concept of
a temporary metric change. You are asking implementations to support the
idea of a temporary change to the currently advertised mettric w/o
altering the saved configuration. This certainly can be done w/o
extending the protocol - so there is no need to "remember/write-down the
existing IS-IS metric that was configured *before* I begin the
maintenance". You would simply remove the temporary config and the
router would automatically revert to the saved config. Internally this
has to be done regardless of whether you use the TLV or not.

At the risk of repeating myself (again!!) I would emphasize the only
difference between what you want and what I want is whether it requires
a protocol extension to do it - we aren't disagreeing on the
functionality that is desirable.

   Les

> "always get it right", as you seem to imply above, and certainly as
our
> executives (and customers) want us to.  Codifying something like the
> Reverse Metric TLV in the protocol allows operators to have a
> _repeatable_, interoperable mechanism that will dramatically reduce
the
> risk of 'human error' for a widely accepted & used operational
practice
> (link isolation).  Given that all public studies I've seen classify
> 'human error' as the dominant cause of network outages, one would
think
> we should be looking at ways to remedy that ...
> 
> -shane

---

From: Shane Amante <[email-masked]>
Date: Mon, 6 Dec 2010 15:23:27 -0700

Les,

> has to be done regardless of whether you use the TLV or not.

It sounds to me like you're unwilling to consider (or, acknowledge?) that the primary reason for the Reverse Metric draft is to solve for deterministic isolation of point-to-point interfaces, which is the dominant link type in the network.  Is this a fair assessment?

-shane

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 7 Dec 2010 07:29:03 +0100 (CET)

> of the Reverse Metric TLV and its associated complexities.

I'd imagine anyone working daily using CLI to administer their large 
network would greatly appreciate this "convenience" as you call it.

I pitched the idea to our ops guys and they were really enthusiastic about 
it, same thing with our NOC guys.

I'd say it probably is the same convenience as having an automatic gearbox 
in your car. It's perfectly fine to shift manually (I personally only buy 
manual gearbox cars), but a lot of people like the convenience of having 
an automatic.

Personally I think the work being done here the past 1-2 months when it 
comes to bringing more functionality into ISIS when it comes to more 
granularity to LAN (having bidir metric to the pseudo node) and the 
reverse metric functionality will make ISIS more usable long term, and 
it's important that we keep doing this. Just because this isn't the 
perfect solution (as "perfect" in this case would be "don't administer the 
network using CLI") I see nothing better on the horizon, so the proposed 
changes would be very welcome.

Considering a lot of other "complexities" being implemented by people 
(RSVP-TE schemes with autobw re-route, MPLS-TP, 1588v2 etc), this seems as 
complex as a walk in the park.

Put simply, the proposed changes to ISIS should have been done a long time 
ago to help the people who work daily to administrate these kinds of 
networks.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Tue, 7 Dec 2010 09:43:47 +0100

[Warning: thinking out loud...]

a) I understand the need to cost out a link with a single CLI on a
single router.
b) I hear that some would prefer management action be done with
management protocols rather than routing protocols extensions.

So what about doing (a) with management protocols? i.e. a router A
providing a single CLI and triggering the remote action on router B
using management protocols.
That would also serve as a test to see by ourselves if this is
convenient or if those management protocols need enhancement. It could
also be reused as an example for NMS to do it by themselves next (next?)
time.

Regards,
Bruno

---

From: "Chen, Jay (Jay)" <[email-masked]>
Date: Tue, 7 Dec 2010 16:29:40 -0600

wide config making each router to be an NMS station. Call it C-ISIS. Example: instead of configuring links on the adjacent nodes configure link parameter anywhere, instead of configuring node at a node .. configure it anywhere.

Very interesting. Configure anywhere by anyone (maybe any computer) will be every powerful and very scaring too (security). A graph of network and transport of configure information will be needed. If protocol is proposed to do the job, should be a single protocol best fit? ISIS does know the topology of the network, on another hand BGP is better to transmit huge data and does incremental updates reliablely. A combination of functions from multiple protocol seems better than extending a single protocol.     
 
Jay

Many thx,
R.

PS.

>> extending protocols to achieve the equivalent functionality.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Dec 2010 23:46:52 +0100

Hi Jay,

Just one clarification ...

What I and also Bruno pointed out was a bit more restrictive that your 
interpretation :)

While each node would be an equal class citizen in such ability to 
configure the network or to set a parameter of a p2p or p2mp link it 
does not mean that one would essentially need to enable such ability on 
each node.

Clearly also it would not be available to anyone. Only to the same 
access level as today allowing for configuration.

As to the topic of what protocol would fit such role I do agree with 
your comment that we would probably need some form of hybrid. The 
reliable domain wide flooding should be combined with incremental 
updates ability.

Volume wise I am not sure we are to have "huge volumes". Clearly what 
differs this type of fundamentally different approach to NMS that it is 
not targetted to be a carrier for SNMP pooling stats or netflow records.

Many thx,
R.

> wide config making each router to be an NMS station. Call it C-ISIS.
> Example: instead of configuring links on the adjacent nodes configure
> link parameter anywhere, instead of configuring node at a node ..
> configure it anywhere.
>
> Very interesting. Configure anywhere by anyone (maybe any computer)
> will be every powerful and very scaring too (security). A graph of
> network and transport of configure information will be needed. If
> protocol is proposed to do the job, should be a single protocol best
> fit? ISIS does know the topology of the network, on another hand BGP
> is better to transmit huge data and does incremental updates
> reliablely. A combination of functions from multiple protocol seems
> better than extending a single protocol.
>
> Jay
>
>
> Many thx, R.
>
> PS.
>
>>> And this is not only in ISIS, we do the same in BGP, we do the
>>> same in MPLS etc ...
>>
>>
>> So, you're suggesting that we stop work on improving protocols
>> until the NMS folks get their act together.
>>
> _______________________________________________ Isis-wg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/isis-wg
>

---

From: Shane Amante <[email-masked]>
Date: Tue, 7 Dec 2010 16:24:52 -0700

Robert, Bruno, (Jay),

It is an explicit /non-goal/, even outside the context of this draft, to port an NMS system and/or configuration generation system *into* IS-IS.  Call me old-school, but a routing protocol, (particularly an IGP), should only distribute topology/reachability information, as fast as [is, safely] possible.  Asking that routing protocol to also push around counters (snmp over IS-IS <barf>), general-purpose configuration information (netconf over IS-IS <barf>), etc. is contrary to that goal for all the reasons that you're already familiar with.  :-)

To be more clear, the scope of this draft is to make operation of an IS-IS network dramatically less error-prone by simplifying the handling of _a_ (notice the explicit use of the singular) very well-known, widely-used, routine maintenance procedure that occurs on networks day-in and day-out, the world over, _specifically_: p2p link /and/ multi-access LAN isolation.

Thanks,

-shane

On Dec 7, 2010, at 15:46 MST, Robert Raszuk wrote:
> What I and also Bruno pointed out was a bit more restrictive that your interpretation :)
> 
> While each node would be an equal class citizen in such ability to configure the network or to set a parameter of a p2p or p2mp link it does not mean that one would essentially need to enable such ability on each node.
> 
> Clearly also it would not be available to anyone. Only to the same access level as today allowing for configuration.
> 
> As to the topic of what protocol would fit such role I do agree with your comment that we would probably need some form of hybrid. The reliable domain wide flooding should be combined with incremental updates ability.
> 
> Volume wise I am not sure we are to have "huge volumes". Clearly what differs this type of fundamentally different approach to NMS that it is not targetted to be a carrier for SNMP pooling stats or netflow records.
> 
> Many thx,
> R.
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 08 Dec 2010 00:35:35 +0100

Hi Shane,

Perhaps my last few mails could be read and interpreted in not intended 
way :)

I am not saying that we should add NMS to ISIS. And I am not saying that 
we should not simplify operation by not extending a routing protocol 
when such extension is obvious like in this draft.

In fact as we speak I am writing a new BGP draft where I use new 
community to configure some behaviour of protocol domain wide. Sure it 
could be achieved by consistent configuration, but there is no point to 
touch 500 routers if I can uniformly and much more easily achieve the 
same by single point config.

My comment were perhaps outside of ISIS WG as such .. I did hijacked the 
thread a bit to just hint the alternative approach to the same problem 
space. If we would solve the main issue neither you nor myself would 
need to extend the protocol and single action resulting in single point 
of config would still yield the required outcome.

That was my point. Above all I am always for simplifying network 
operation. The only question which still remains is to try to do it in 
the best way and most reusable way we can.

Best regards,
R.

> Robert, Bruno, (Jay),
>
> It is an explicit /non-goal/, even outside the context of this draft,
> to port an NMS system and/or configuration generation system *into*
> IS-IS.  Call me old-school, but a routing protocol, (particularly an
> IGP), should only distribute topology/reachability information, as
> fast as [is, safely] possible.  Asking that routing protocol to also
> push around counters (snmp over IS-IS<barf>), general-purpose
> configuration information (netconf over IS-IS<barf>), etc. is
> contrary to that goal for all the reasons that you're already
> familiar with.  :-)
>
> To be more clear, the scope of this draft is to make operation of an
> IS-IS network dramatically less error-prone by simplifying the
> handling of _a_ (notice the explicit use of the singular) very
> well-known, widely-used, routine maintenance procedure that occurs on
> networks day-in and day-out, the world over, _specifically_: p2p link
> /and/ multi-access LAN isolation.
>
> Thanks,
>
> -shane
>
>
>> configure the network or to set a parameter of a p2p or p2mp link
>> it does not mean that one would essentially need to enable such
>> ability on each node.
>>
>> As to the topic of what protocol would fit such role I do agree
>> with your comment that we would probably need some form of hybrid.
>> The reliable domain wide flooding should be combined with
>> incremental updates ability.
>>
>> Volume wise I am not sure we are to have "huge volumes". Clearly
>> what differs this type of fundamentally different approach to NMS
>> that it is not targetted to be a carrier for SNMP pooling stats or
>> netflow records.
>>
>> Many thx, R.
>>
>>> wide config making each router to be an NMS station. Call it
>>> C-ISIS. Example: instead of configuring links on the adjacent
>>> nodes configure link parameter anywhere, instead of configuring
>>> Very interesting. Configure anywhere by anyone (maybe any
>>> computer) will be every powerful and very scaring too (security).
>>> A graph of network and transport of configure information will be
>>> needed. If protocol is proposed to do the job, should be a single
>>> protocol best fit? ISIS does know the topology of the network, on
>>> another hand BGP is better to transmit huge data and does
>>> incremental updates reliablely. A combination of functions from
>>> multiple protocol seems better than extending a single protocol.
>>>
>>> Jay
>>>
>>>
>>> Many thx, R.
>>>
>>> PS.
>>>
>>>>> Instead of working on network wide level config tool/protocol
>>>>> we are extending protocols to achieve the equivalent
>>>>> functionality. And this is not only in ISIS, we do the same
>>>>> in BGP, we do the same in MPLS etc ...
>>>>
>>>>
>>> _______________________________________________ Isis-wg mailing
>>> list [email-masked]
>> _______________________________________________ Isis-wg mailing
>> list [email-masked]

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 09:43:20 +0100

Shane,

> It is an explicit /non-goal/, even outside the context of this draft,
to
> port an NMS system and/or configuration generation system *into*
IS-IS.
> Call me old-school, but a routing protocol, (particularly an IGP),
should
> only distribute topology/reachability information, as fast as [is,
safely]
> possible.  Asking that routing protocol to also push around counters
(snmp
> over IS-IS <barf>), general-purpose configuration information (netconf
> over IS-IS <barf>), etc. is contrary to that goal for all the reasons
that
> you're already familiar with.  :-)

May be I was not clear in my previous email but your above text does not
reflect what I meant.

1) From a protocol standpoint, by

> From: [email-masked]
> 

I meant _regular_ management protocols. E.g SNMP over UDP/IP or netconf
over TCP/IP. Nothing related to IS-IS, especially _not_ "snmp over IS-IS
<barf>"

2) From a general standpoint, I did not mean to port NMS into IS-IS,
quite the contrary in fact.

Bruno

> To be more clear, the scope of this draft is to make operation of an
IS-IS
> network dramatically less error-prone by simplifying the handling of
_a_
> (notice the explicit use of the singular) very well-known,
widely-used,
> routine maintenance procedure that occurs on networks day-in and
day-out,
> the world over, _specifically_: p2p link /and/ multi-access LAN
isolation.
> configure the network or to set a parameter of a p2p or p2mp link it
does
> not mean that one would essentially need to enable such ability on
each
> node.
reliable
> domain wide flooding should be combined with incremental updates
ability.
> > Volume wise I am not sure we are to have "huge volumes". Clearly
what
> >> wide config making each router to be an NMS station. Call it
C-ISIS.
> >> _______________________________________________ Isis-wg mailing
list

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 09:53:09 +0100

> Nice in theory.  What mgmt protocol will
> A) figure out the peer router
> B) figure out the peer link on said peer router
> C) temporarily cost out that link
> D) in a multiple-vendor network?

So if it's difficult / impossible, may be NMS or SP network management
systems are not the one to blame, actually. May be current IETF
management tools / framework need to be extended.

Regards,
Bruno

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 8 Dec 2010 22:05:46 +1100

Greetings Bruno,

> management tools / framework need to be extended.

And we've attempted that, Bruno, for those last 20 years.  When/if we obtain that grail, we will all be grateful, however, I've given up holding my breath for that.....

	Chris

> Bruno

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 8 Dec 2010 10:47:58 +1100

Greetings all,

> On a more serious note, it's important to recognize that in order to mitigate human-error, we need to reduce the burden on operators to "always get it right", as you seem to imply above, and certai…

I support Shane in this concise description of the problem.  We CAN do it (in most cases) with what we have now, we WILL (and do) bork then network some percentage of the time when doing so.  This is an anti-borking approach, and I support it.  The problem will just get worse as the interface and meshing ratios go up, which they inevitably will.

	Chris

---
李柯睿
Check my PGP key here:

---
李柯睿
Check my PGP key here:

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 8 Dec 2010 10:49:07 +1100

Greetings Robert,

On 07Dec2010, at 07.42, Robert Raszuk wrote:

> The problem is that this is nearly 2011 and we still do not have a good way to configure networks as an entire abstraction. We do at most - in sophisticated networks - have scripts to configure routers on a box to box basis.
> 
> So while I am not seeing any harm with this draft as is I think at some point we should put serious effort to look at the network as an abstraction layer and configure such abstraction layer rather then continue the trend of extending routing protocols to deliver equivalent functionality.

And the quest for that holy grail has been going on in this forum for well nigh 20 years.  When it comes, we will all bow down before it and celebrate for a solid year.  Until then, we have networks to run.....

:)

Chris

> That IMHO would be the best way to address the "human error" issue.

- ---
李柯睿
Check my PGP key here:

---

From: Christopher Liljenstolpe <[email-masked]>
Date: Wed, 8 Dec 2010 12:23:55 +1100

Greetings,

Sent from a slightly less silly keyboard.

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 8 Dec 2010 22:03:42 +1100

Greetings Les,

> has to be done regardless of whether you use the TLV or not.
The difference is that, by doing this via a temporary config method, it would have to be done at both ends (see my earlier comments).  In  Shane's model, it only needs to be done in one router.

---
李柯睿
Check my PGP key here:

---

From: Ilya Varlashkin <[email-masked]>
Date: Thu, 9 Dec 2010 20:52:42 +0100

(catching up on few days of not reading ietf lists)

Les,

the alternatives you provide aren't equally attractive to network operators as what the draft proposes. Please see below.

> configure the reverse metric TLV to be sent to the other neighbor
The 'AND' part is done simply by adding option to metric command, e.g. 'set metric 1000 bidir' whereas doing it on two routers requires at least a) connecting to the router, b) finding appropriate interface, c) going to config mode to do changes, or in short - way to much typing for 3am, and somebody will change metric on a wrong interface, or worse - on a wrong router.

> Multi-Access LANs
Changing cost to a single node in P-LSP requires typing some kind of ID of that node - prone to errors. And that's very important difference (again from operator's perspective) between the draft and your proposal.

> of the Reverse Metric TLV and its associated complexities.

convinience for operators is a good reason to change protocol as long as we don't break anything, isn't it?. After all protocols are just means for operators to have things done and done good.

Kind regards,
iLya

---

From: Ilya Varlashkin <[email-masked]>
Date: Thu, 9 Dec 2010 21:06:26 +0100

> using management protocols.

That sounds much more complicated than what the draft suggests, and doesn't even solve everything what the draft solves ('last-resorting single node on a multi-access LAN'). First it requires manager-side (As opposed to the agent) of a management protocol (SNMP, NETCONF, you-name-it). Second, either manager- or agent-side would have to perform quite sophisticated work to find out appropriate interface that needs to be altered (since we don't error-prone humans to do it). And finally, there must be then place where operator could see why on the earth metric of an interface isn't the same as in the config (easy with 'Reverse Metric TLV' - it's in the neighbor info).

Also looking from completely different angle, there is one application for Reverse Metric TLV that cannot and should not be done via manual or automated config management. I've already mention it when topic first popped up several weeks ago - Reverse Metric TLV can nicely solve problem of LDP-IGP sync on multi-access LAN. For P2P now routers just set overload bit or max-out intf metric, but that doesn't work on multi-access LAN because existing solutions are too coarse for it. Reverse Metric TLV provides fine granularity that allows quite elegant implementation of LDP-IGP sync on multi-access networks.

Kind regards,
iLya

---

From: <[email-masked]>
Date: Fri, 10 Dec 2010 10:20:45 +0100

Hi all,

>From my experience point of view, for the specific framework of ISIS rerouting, there is a real need of "global configuration". Some years ago, we managed ISIS rerouting (changing metrics to high then changing back to normal to prevent traffic going on link during maintenance or link flaps) on box to box basis, people were configuring each box individually and we had some human errors on that ... To secure the operation, we developped a tool which is doing all configurations (multibox/multivendor configuration) by itself, this helped us to prevent human errors and it worked fine, but this requires extra coding (link end point detection , multi vendor configuration management ...). For our point of view, it clearly easier to manage configurations on box to box basis rather than coding complex tools (so I'm quite happy with this draft from this point of view).
If we look at network configurations more globally (not only ISIS), we are trying to work in the same way as for ISIS rerouting, we are developping tools that configures the network globally (example for BGP session, the tool is configuring both sides, for physical links or VLANS, scripts are configuring all stuffs : ports, vlans, routers, switches between ...). It's very very useful to secure operations and prevent human errors but it's very hard to us because the codes are sometimes very complex and more over we have to manage multiple vendor configurations within the same code (we must detect the vendor when connecting on the node).

Regards,

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Robert Raszuk
Envoyé : lundi 6 décembre 2010 21:43
À : [email-masked]
Objet : Re: [Isis-wg] draft-amante-isis-reverse-metric-01

All,

Cheers,
R.

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************