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

[Ilya Varlashkin <[e-mail]>]

(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.
On Dec 6, 2010, at 17:51 , Les Ginsberg (ginsberg) wrote:

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

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

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