Subject: Re: [Isis-wg] operational problem might be solved by somehowextending current IS-IS

From: [email-masked]
Date: Sat, 18 Sep 2010 11:48:49 +0200

> On Sep 17, 2010, at 10:02 AM, Chen, Jay (Jay) wrote:
> 
>> _If_ current implementations permit (will not balk in the presence of) 
>> non-zero metric from
>> 
>> Depending on how much you define balk. Some implementation assumes zero metric in pseudo-node, also prioritise for ECMP path. However I think reverse metric is a less risky option.  
> 
> 
> That's not yet clear to me.  If an IS doesn't support the reverse metric TLV, then it will compute different SPF results than an IS that does.  That seems like it is guaranteed to create forwarding loops.
> 
> Please feel free to convince me otherwise.  Mathematical proofs preferred.  ;-)
> 
> Tony

if some node ignore non-zero metric reported by DIS when they do SPF then we can only do more harm, on the other hand, can it be any capability negotiation taking place before hand?

Guan

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 20 Sep 2010 08:18:09 +0200

> -----Original Message-----
> > That's not yet clear to me.  If an IS doesn't support the 
> reverse metric TLV, then it will compute different SPF 
> results than an IS that does.  That seems like it is 
> guaranteed to create forwarding loops.
> > 
> if some node ignore non-zero metric reported by DIS when they 
> do SPF then we can only do more harm, on the other hand, can 
> it be any capability negotiation taking place before hand?
> 

I don't think capability negotiation will change much, because non-zero
metric pseudo-node LSP can come from another segment. It quite easy to
demonstrate that reverse metric _will_ do harm if there are routers that
do not permit non-zero metric in pseudo-node for which the router with
'reverse metric' is potential upstream (no problem if it's only
downstream). Likewise, it's trivial to demonstrate that if all routers
within the level allow non-zero pseudo-node metric (other level is ok)
then SPF calculations will be consistent within that level even if
advertising router and DIS on that segment are the only routers
understanding 'reverse metric' TLV.

/iLya

---

From: [email-masked]
Date: Mon, 20 Sep 2010 08:45:23 +0200

> understanding 'reverse metric' TLV.

Ok, so if we want this feature, it has to be supported on all node in that level in other word, this is might not always the case ;)

If this whole thing is initialed on the DIS, the DIS can decide whether to advertise non-zero metric or not, if it knows there are some host
do not support such feature in this level... thus we can ensure backwards compatibility, right?

Cheers
Guan

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 20 Sep 2010 08:50:08 +0200

> > I don't think capability negotiation will change much, because 
> > non-zero metric pseudo-node LSP can come from another segment. It 
> > quite easy to demonstrate that reverse metric _will_ do 
> harm if there 
> > are routers that do not permit non-zero metric in pseudo-node for 
> > which the router with 'reverse metric' is potential upstream (no 
> > problem if it's only downstream). Likewise, it's trivial to 
> > demonstrate that if all routers within the level allow non-zero 
> > pseudo-node metric (other level is ok) then SPF 
> calculations will be 
> > consistent within that level even if advertising router and DIS on 
> > that segment are the only routers understanding 'reverse 
> metric' TLV.
> > 
> > /iLya
> 
> Ok, so if we want this feature, it has to be supported on all 
> node in that level in other word, this is might not always the case ;)
> 

No, it ('reverse metric' TLV) doesn't need to be supported on every
node, all what's required is to ensure that all nodes within same level
allow non-zero metric from pseudo-node. This is why it's necessary to
poll implementors regarding whether or not their current implementation
will allow non-zero metric. If non-zero metric is permitted, then even
if a node doesn't recognise 'reverse metric' TLV it still executes
normal SPF and calculates path based on metric advertised by DIS.

> If this whole thing is initialed on the DIS, the DIS can 
> decide whether to advertise non-zero metric or not, if it 
> knows there are some host do not support such feature in this 
> level... thus we can ensure backwards compatibility, right?
> 
Not really. Initiation by DIS or by DIS reaction on 'reverse metric' TLV
are not different in what happens afterwards.

Cheers,
iLya

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 20 Sep 2010 12:41:36 +0200 (CEST)

> poll implementors regarding whether or not their current implementation

I see serious risk by implementing it this way, and also it doesn't really 
solve my problem completely (p-t-p doesn't get bidir cost).

I suggest a new "mode", the same way one can configure "isis network 
point-to-point" I'd like to se "isis network bidir-metric". This would 
generate only a new kind of TLV, which has bidirectional metric. This 
would mean that implementations which do not recognise this new type will 
just ignore it and not see the adjacancy at all?

Just the way one can migrate a network from "narrow" to "wide" metrics by 
using "transitional" it would be beneficial if there also was a 
"transition-mode" for these TLVs.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 20 Sep 2010 13:55:22 +0200

> > node, all what's required is to ensure that all nodes within same 
> > level allow non-zero metric from pseudo-node. This is why it's 
> > necessary to poll implementors regarding whether or not 
> their current 
> > implementation
> 
> I see serious risk by implementing it this way, and also it 
> doesn't really solve my problem completely (p-t-p doesn't get 
> bidir cost).
> 

on the contrary, p2p is much easier - upon receiving 'reverse metric'
TLV adjacent router will simply modify its own direct metric, the rest
is compatible 100% with any existing implementation (as nobody would be
able to tell new metric from the other).

/iLya

---

From: [email-masked]
Date: Mon, 20 Sep 2010 14:27:53 +0200

> normal SPF and calculates path based on metric advertised by DIS.

agree 

> are not different in what happens afterwards.

what i mean here is that, if the DIS knows for example there are some nodes in it's is-is level ignores non-zero metric( during the SPF process), the DIS should not advertise non-zero metric at all, it will be 
advertised only if all nodes in that level explicitly say "i do support non-zero metric", sounds dull, but how can u ensure backwards compatibility and no routing loops...

---

From: mike shand <[email-masked]>
Date: Mon, 20 Sep 2010 15:07:20 +0100

So let me see if I can summarise what is being proposed here.

1) A new IIH "reverse cost" TLV that specifies the desired metric for 
any link TO this interface.

When this is received by a pt-pt interface it causes an implementation 
that understands it to increase its OWN normal metric over that 
interface to the specified value. If it doesn't understand it, nothing 
happens.

In the case of a broadcast interface, ONLY the DIS takes note of this, 
and if it understands it, increases the cost FROM the pseudonode to the 
issuing node (only).

2) We assume that ALL implementations will correctly accept and compute 
costs from a pseudonode. If this is not the case we are in trouble! 
Introducing some kind of capability to say that we do accept non-zero 
pseudonode costs has been proposed, so we would ONLY action the "reverse 
cost" TLV  on a pseudonode if ALL nodes support it, but this is somewhat 
dangerous and can lead to all sorts of trouble if a node which doesn't 
support it comes and goes.

Have I understood what is being proposed correctly?

     Mike

On 20/09/2010 13:27, [email-masked] wrote:
> _______________________________________________
> 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

---

From: Tony Li <[email-masked]>
Date: Mon, 20 Sep 2010 08:10:35 -0700

Mike,

With respect to 2), rather than assuming that implementations will process things correctly, some folks feel that a survey of implementations is in order.  In the case where all implementations already Do The Right Thing, we might be able to move forward more rapidly.

Regards,
Tony

On Sep 20, 2010, at 7:07 AM, mike shand wrote:

> 1) A new IIH "reverse cost" TLV that specifies the desired metric for any link TO this interface.
> 
> When this is received by a pt-pt interface it causes an implementation that understands it to increase its OWN normal metric over that interface to the specified value. If it doesn't understand it, nothing happens.
> 
> In the case of a broadcast interface, ONLY the DIS takes note of this, and if it understands it, increases the cost FROM the pseudonode to the issuing node (only).
> 
> 2) We assume that ALL implementations will correctly accept and compute costs from a pseudonode. If this is not the case we are in trouble! Introducing some kind of capability to say that we do accept non-zero pseudonode costs has been proposed, so we would ONLY action the "reverse cost" TLV  on a pseudonode if ALL nodes support it, but this is somewhat dangerous and can lead to all sorts of trouble if a node which doesn't support it comes and goes.
>

---

From: Mohan Nanduri <[email-masked]>
Date: Mon, 20 Sep 2010 11:28:42 -0400

Will the reverse-cost TLV handle TE-metrics also?

Cheers,
-Mohan

On Mon, Sep 20, 2010 at 11:10 AM, Tony Li <[email-masked]> wrote:

>
> Mike,
>
> With respect to 2), rather than assuming that implementations will process
> things correctly, some folks feel that a survey of implementations is in
> order.  In the case where all implementations already Do The Right Thing, we
> might be able to move forward more rapidly.
>
> Regards,
> Tony
>
>
> that understands it to increase its OWN normal metric over that interface to
> the specified value. If it doesn't understand it, nothing happens.
> >
> >> what i mean here is that, if the DIS knows for example there are some
> nodes in it's is-is level ignores non-zero metric( during the SPF process),
> the DIS should not advertise non-zero metric at all, it will be
> >> advertised only if all nodes in that level explicitly say "i do support
> non-zero metric", sounds dull, but how can u ensure backwards compatibility
> and no routing loops...
> >>
> >>
> >>> Cheers,
> >>> iLya

---

From: mike shand <[email-masked]>
Date: Mon, 20 Sep 2010 16:41:44 +0100

Tony,

     Indeed, IIF that is the case, then we would be in good shape.

     Mike

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 27 Sep 2010 11:47:38 -0700

Is Mike's summary an accurate statement of where this thread has ended
up?

If so, I would like to express my strong reservations about any proposal
where the protocol is used to override the local configuration on Node A
by configuring something on Node B which B then sends to A. I think this
is a recipe for great confusion - and as this thread was motivated by
trying to make the life of the network administrator easier/less
confusing I think this is counter-productive. 

If one wants to quickly bring down an adjacency (i.e. w/o waiting for
timeout) we have the means to do that w/o protocol extensions - as has
been pointed out on this thread. This works for both the P2P as well as
broadcast circuits.

If one wants to quickly disable a broadcast circuit, it is possible to
do that by going to the DIS and disabling/purging the pseudo-node LSPs
for that link. 

What is NOT covered by the above two strategies is the case where one
does not want to completely disable the link (or a given node's use of
that link) but wants to make it a path of last resort. It isn't clear to
me how compelling this case is given that this thread started with a
maintenance scenario (e.g. a link is having bit errors), so I am
inclined to be conservative in defining protocol extensions as the
potential benefits are quite limited.

To handle this last case it seems there are two strategies that require
no protocol extensions:

a)Configure the DIS to assign max-metric in the pseudo-node LSP to one
or more nodes. This has some risk of backwards compatibility issues as
has been discussed.

b)Configure both ends of a P2P circuit with max-metric

In the absence of a compelling benefit (which I have yet to see
articulated) I think the above strategies are sufficient.

   Les

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mike Shand (mshand)
> Sent: Monday, September 20, 2010 7:07 AM
> To: [email-masked]
> Subject: Re: [Isis-wg] operational problem might be solved
> bysomehowextending current IS-IS
> 
> 
> level
> >> Not really. Initiation by DIS or by DIS reaction on 'reverse
metric'
> TLV
> nodes in it's is-is level ignores non-zero metric( during the SPF
> process), the DIS should not advertise non-zero metric at all, it will
> be
> > advertised only if all nodes in that level explicitly say "i do
> support non-zero metric", sounds dull, but how can u ensure backwards
> compatibility and no routing loops...
> >
> >
> >> Cheers,
> >> iLya

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 27 Sep 2010 21:29:41 +0200 (CEST)

> potential benefits are quite limited.

I don't know what to say apart from "a link with bit errors is better than 
no link at all". if there are other paths, I want to use them. If there is 
no other path, I want to use the one with bit errors.

How "compelling" this is in eye of the beholder. If you ask someone doing 
operations I can assure you they see benefit in being able to 
bidirectionally (ie easily) assign a cost to a link to make it "last 
resort" by just changing the config at one end.

Someone not doing operations, I can understand that they don't see this 
benfit, or see the benfit being not enough to warrant a protocol change.

It's a subjective cost/benefit analysis.

I've seen enough cases where someone forgot to increase the metric at one 
end to say that's enough to warrant a protocol change (thinking we'll 
still use ISIS 10 years from now), but looking at "next quarter", I'm sure 
someone can make a very compelling argument that operations people are 
lazy and just want the convenient solution, and that implementing a system 
to increase the metric at both ends is just fine.

I still want the bidir metric change in the protocol after all the above 
reasoning, I see the lack of it costing us money in mistakes at least 
one a year.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 27 Sep 2010 13:41:02 -0700

Mikael -

I am not arguing that we should not provide a way to make a path "last
resort" and in fact we can do that today w/o protocol extensions - it is
a matter of "convenience" that is being discussed. A number of
enhancements to make it more convenient/expedient to support the
scenarios you have raised have been identified in this thread - and in
most cases clever implementors have done these things - though they may
not be available from YFRV(s).

But once you introduce a model which allows the local configuration on
Node A to be overwritten by any other node based on advertisements in
IS-IS PDUs I think you have the makings of great confusion and you are
now using the protocol to define configuration - which is not at all
what it is intended to do and opens us up to many abuses and/or new ways
of introducing misconfiguration.

We have MIBs and management stations and management tools for a reason -
would it not be better to use these tools?

   Les

> Behalf Of Mikael Abrahamsson
> Sent: Monday, September 27, 2010 12:30 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; Mike Shand (mshand)
> > that link) but wants to make it a path of last resort. It isn't
clear
> to
> no link at all". if there are other paths, I want to use them. If
there
> is

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 28 Sep 2010 07:48:31 +0200 (CEST)

> of introducing misconfiguration.

That is not what I'm proposing. It might be what others were talking 
about, but that was definitely never my original intent.

What I want is for the link metric to have two metrics, in and out. So the 
receiving node of a PDU takes the metric of the received PDU and adds it's 
own IN metric, and then uses the addition of these two as the metric of 
the link.

R1 has
IN metric 5
OUT metric 10

R2 has
IN metric 5
OUT metric 10

Now both routers agree that the metric of the link is 15 bidirectionally.

If R2 changes both his values to 100 then R1->R2 gets a metric of 105 and 
R2->R1 gets a metric of 110. The configuration of R1 never changes.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 27 Sep 2010 23:06:05 -0700

So you are suggesting we change the basic operation of the protocol (how
it computes SPT) solely so that we can more conveniently do link/node
maintenance every now and then. This is hard to justify.

   Les

> Sent: Monday, September 27, 2010 10:49 PM

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 28 Sep 2010 08:34:11 +0200 (CEST)

> maintenance every now and then. This is hard to justify.

Well, as far as I see it the (IN+OUT) metric could be treated the same as 
the current metric and communicated to others in the same way. This of 
course means both ends need to know about this new standard way of 
computing metric, but nobody else would need to know about it as far as I 
can see?

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 28 Sep 2010 00:03:42 -0700

Mikael -

If you wish traffic to be directed away from a particular node/link then
clearly the upstream routers have to calculate the cost in the same way
that the neighbors on the circuit do. Waiting until the packet arrives
at the node in question to use the adjusted cost will create forwarding
loops in cases where the lowest cost path from the node in question to
the destination traverses a path via an upstream router. So this change
is NOT confined to the neighbors. 

   Les

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Monday, September 27, 2010 11:34 PM
> Subject: RE: [Isis-wg] operational problem might be solved
> computing metric, but nobody else would need to know about it as far
as
> I

---

From: Tony Li <[email-masked]>
Date: Tue, 28 Sep 2010 00:58:40 -0700

Les,

There is a semantic that would accomplish that, however.

Suppose that we define an IIH TLV that is the "reverse metric increment".

On reception on a PTP link, the receiver adds the value in the TLV to its normally configured metric and advertises the result instead of its normal link metric.

This requires zero participation from any other IS, and if it is not understood by the receiving IS, fails safely and gracefully: nothing changes.

Tony

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Tue, 28 Sep 2010 13:50:01 -0400

Tony,

That's pretty elegant .. one quick question.

What would be the proposed semantics if both ends sent a reverse metric
increment?

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tony Li
Sent: Tuesday, September 28, 2010 3:59 AM
To: Les Ginsberg (ginsberg)
Cc: Mike Shand (mshand); [email-masked]
Subject: Re: [Isis-wg] operational problem might be solved
bysomehowextending current IS-IS

Les,

On reception on a PTP link, the receiver adds the value in the TLV to its
normally configured metric and advertises the result instead of its normal
link metric.

This requires zero participation from any other IS, and if it is not
understood by the receiving IS, fails safely and gracefully: nothing
changes.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 28 Sep 2010 10:56:02 -0700

Peter,

It's completely symmetric.

Suppose that A and B share a link.  Original metrics are A:2 B:3.

Suppose that A requests an increment of 11 and B requests an increment of 17.

Then A changes to advertise 19, and B advertises 14.

Note that for the purposes of link depreferencing for maintenance, the more likely scenario is that A would request that B add 'a really big number' and would also raise its own metric to 'a really big number'.  ;-)

Tony

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Tue, 28 Sep 2010 14:13:02 -0400

Ok, that makes sense .... very elegant. 

Presumably asking to increment by the maximum link metric would just cause
the neighbour to advertise the max not increment and wrap?

Would it make sense to allow a decrement direction also?

I like it .. only a few hours to implement and easy to test/migrate.

Gets my vote ...

Peter

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: Tuesday, September 28, 2010 1:56 PM
To: Peter Ashwood-Smith
Cc: 'Les Ginsberg (ginsberg)'; 'Mike Shand (mshand)'; [email-masked]
Subject: Re: [Isis-wg] operational problem might be solved

Peter,

Suppose that A requests an increment of 11 and B requests an increment of
17.

Note that for the purposes of link depreferencing for maintenance, the more
likely scenario is that A would request that B add 'a really big number' and
would also raise its own metric to 'a really big number'.  ;-)

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 28 Sep 2010 11:31:38 -0700

> the neighbour to advertise the max not increment and wrap?

Yup.

> Would it make sense to allow a decrement direction also?

What's the use case?

> I like it .. only a few hours to implement and easy to test/migrate.

Only for those of you in low-overhead organizations.  ;-) ;-) ;-)

Tony

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Tue, 28 Sep 2010 14:43:38 -0400

>What's the use case?

Attract traffic bi-directionally to a link without changing both ends. Just
seems like the knob should worth in both directions for completeness. 

> Only for those of you in low-overhead organizations.  ;-) ;-) ;-)

Touche... gone are those fun days of quick agreement/implementation and
deployment eh!

Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 28 Sep 2010 11:51:22 -0700

Tony -

Yes - it could be done this way. But we are back to the model where the
local configuration of Node A is overridden by TLVs sent from Node B -
which I simply don't like for reasons I have previously stated.

I am sympathetic with the need to make maintenance more convenient - but
to me this is the province of management tools - not protocol
extensions.

Having set this precedent, I think we are on a slippery slope where any
case which requires "simultaneous" changes to the configs on multiple
routers is a candidate for some new protocol advertisement.

   Les

> Sent: Tuesday, September 28, 2010 12:59 AM
> Cc: Mikael Abrahamsson; [email-masked]; Mike Shand (mshand)
> On reception on a PTP link, the receiver adds the value in the TLV to
> its normally configured metric and advertises the result instead of
its
> normal link metric.
> >>> So you are suggesting we change the basic operation of the
protocol
> >> (how
> >> Well, as far as I see it the (IN+OUT) metric could be treated the
> same
> >> as

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 28 Sep 2010 11:54:25 -0700

Hi Les,

I agree with what you say. It also adds another security vector we
need to cinsider.

Thanks,
Vishwas

---

From: Tony Li <[email-masked]>
Date: Tue, 28 Sep 2010 11:55:23 -0700

> seems like the knob should worth in both directions for completeness. 

Let me rephrase: what's the operational benefit to doing this?

I'm being cautious because passing around signed integers invites more bugs.  

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 28 Sep 2010 12:01:26 -0700

Hi Les,

> to me this is the province of management tools - not protocol

I share your concern and am not yet convinced that this is worthwhile on PTP links.  On the LAN, I think that the case is far more compelling.  There we can provide functionality that is simply not possible with management tools today.

> routers is a candidate for some new protocol advertisement.

Let's be clear.  Nothing here is going to be "simultaneous".  ;-)

Tony

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 28 Sep 2010 21:10:48 +0200 (CEST)

On Tue, 28 Sep 2010, Tony Li wrote:

> I share your concern and am not yet convinced that this is worthwhile on 
> PTP links.  On the LAN, I think that the case is far more compelling.

I see this as completely misguided. What would happen operationally is 
that we'd most likely start treating all ptp links as LAN (perhaps even 
requesting vendors to implement support for this on POS if it's not 
possible today) just to gain the functionality I'm after. We'd be willing 
to sacrifice the added (pseudo)nodes in SFP to give the operational easing 
(we've had operational problems because someone forgot to do both ends).

Wonder what'd happen by using it as LAN and then doing "passive only", if 
we'd get the functionality but without the pseudo-nodes at all.

If bidirectional metric is done for the LAN, it should definitely be 
implemented on ptp as well. Either do this across the line or don't do it 
at all.

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Tue, 28 Sep 2010 15:21:35 -0400

> I'm being cautious because passing around signed integers invites more
bugs. 

Agreed .. I was thinking actually of an flag/enum { increment, decrement } 

Operationally it just saves a provisioning step when you want to lower the
cost of a link and if you care about symmetry it also minimizes asymetric
behavior during the interval between each end being decreased.

Anyway I just suggest it for completeness .. not dogmatic about it, its
certainly not as useful as the increment direction.

Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 28 Sep 2010 12:24:51 -0700

> Sent: Tuesday, September 28, 2010 12:01 PM
> I share your concern and am not yet convinced that this is worthwhile
> on PTP links.  On the LAN, I think that the case is far more
> compelling.  There we can provide functionality that is simply not
> possible with management tools today.

Apologies for restating some things but...

If what is desired is to disable a LAN then all that is needed is to log
on to the DIS and issue a command which purges/suppresses pseudo-node
LSPs - thereby eliminating two-way connectivity. This could be done
easily and w/o protocol extensions.

What we are then left with is the need to "conveniently" make the LAN a
path of last resort - as opposed to disabling it. I believe this could
be achieved with a smart management tool which queries the set of
neighbors on the LAN and then sets the cost on the LAN on each one of
the neighbors to max-metric. 

I am having a hard time seeing this both as so compelling and so
extraordinarily difficult for a management tool that we have to start
turning the protocol into a management application.

??

   Les

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 28 Sep 2010 21:35:36 +0200 (CEST)

> the neighbors to max-metric.

It's not a matter of making the LAN a last resort, is making one of the 
ways out of the LAN as a last resort. Think 5 routers, 2 of them connect 
the LAN to the rest of the core network. Now we want to make one of them 
the last resort because we're going to do maintenance (or the port to the 
LAN switch has errors and someone has to drive 8 hours to get on-site).

This has been stated earlier in the discussion, so yes, you're restating, 
and I'm also restating.

> turning the protocol into a management application.

I can send nanog-l an email about the discussion and see if there are more 
operational people who think the whole idea is worthwile?

I don't know how many would agree that my request is turning ISIS into a 
"management application", I surely don't. Just because something can be 
done via a management application doesn't mean anything else doing it is 
also a management application.

---

From: Shane Amante <[email-masked]>
Date: Tue, 28 Sep 2010 13:50:48 -0600

Les,

> which I simply don't like for reasons I have previously stated.

While I respect your opinion, the reasons I've heard you articulate in a previous e-mail seem to be a matter of "personal preference"/taste.  More to the point, operators are used to protocols "overriding" local configuration for eons.  A few examples, off the top of my head:
- IS-IS DIS priority and OSPF DR/DBR priority
  + change priority on a non-DIS or BDR to be higher; no changes are reflected in the "priority" CLI config cmd of the previous DIS or DR -- only "show" CLI commands will tell you who is the current DIS/DR.
- BGP hold-time, (negotiated by both sides to be the lowest, only CLI "show" commands show you what it was negotiated to)
- BGP policy, (i.e.: an eBGP neighbor blocking a recv'd announcement due to filtering on AS_PATH, community, etc.)

If anything, the big advantage to making this change "reverse-metric" change in IS-IS is that it's an IGP protocol, so both ends are owned/operated by the same organization so it's more "straightforward" to troubleshoot than, for example, eBGP.  (If I *really* had to I can login to both routers and observe what's happening).

Ultimately, all this means is that an implementation will have to clearly expose in "show" CLI commands a "configured" metric and a "actual/received" metric.  This shouldn't be terribly hard, given the past precedent in numerous protocols.

> to me this is the province of management tools - not protocol

Sorry to burst your bubble, but your "faith" in NMS systems is misplaced.  :-)  Unfortunately:
1)  Vendor-provided NMS'es don't know how to deal with 3rd-party equipment;
2)  Non-vendor provided NMS'es that can deal with a variety of 3rd-party equipment either:
    a)  Don't cover all equipment one inevitably uses; or,
    b)  Don't cover all the features (especially in a timely manner) of all equipment

For better or worse, CLI is what we've got and it's (mostly) always kept up-to-date wrt the shipping software revision you get with equipment.  (Hopefully, NETCONF might get here).

-shane

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 28 Sep 2010 12:58:31 -0700

Shane -

> From: Shane Amante [mailto:[email-masked]]
> Sent: Tuesday, September 28, 2010 12:51 PM
> Cc: Tony Li; Mike Shand (mshand); [email-masked]
> While I respect your opinion, the reasons I've heard you articulate in
> a previous e-mail seem to be a matter of "personal preference"/taste.
> More to the point, operators are used to protocols "overriding" local
> configuration for eons.  A few examples, off the top of my head:
>   + change priority on a non-DIS or BDR to be higher; no changes are
> reflected in the "priority" CLI config cmd of the previous DIS or DR --
> only "show" CLI commands will tell you who is the current DIS/DR.

This does not change the operational config on another router - it only changes the config on the router on which the CLI command was issued. So this is hardly the same case. Similarly with the other examples you cite below.

> - BGP hold-time, (negotiated by both sides to be the lowest, only CLI
> "show" commands show you what it was negotiated to)
> - BGP policy, (i.e.: an eBGP neighbor blocking a recv'd announcement
> due to filtering on AS_PATH, community, etc.)
> 
> If anything, the big advantage to making this change "reverse-metric"
> change in IS-IS is that it's an IGP protocol, so both ends are
> owned/operated by the same organization so it's more "straightforward"
> to troubleshoot than, for example, eBGP.  (If I *really* had to I can
> login to both routers and observe what's happening).
> 
> Ultimately, all this means is that an implementation will have to
> clearly expose in "show" CLI commands a "configured" metric and a
> "actual/received" metric.  This shouldn't be terribly hard, given the
> past precedent in numerous protocols.
> 
> 

Don't worry - you haven't burst my bubble. :-)
I am not that naïve in regards to how well management tools work today - but I also have seen some examples of how well they could work. I think the cry here from folks like yourself is "we need better tools" - and I am happy to support you in that - but let's focus on the right place to do this work. In my view it isn't adding extensions to the protocol to allow it to change the operational state of its neighbors.

   Les

> 
> For better or worse, CLI is what we've got and it's (mostly) always
> kept up-to-date wrt the shipping software revision you get with
> equipment.  (Hopefully, NETCONF might get here).
> 
> -shane
> 
> 
> >>>> the current metric and communicated to others in the same way.
> This
> >> of

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 28 Sep 2010 22:01:39 +0200 (CEST)

On Tue, 28 Sep 2010, Les Ginsberg (ginsberg) wrote:

> This does not change the operational config on another router - it only 
> changes the config on the router on which the CLI command was issued. So 
> this is hardly the same case. Similarly with the other examples you cite 
> below.

The bidir proposal doesn't change the config of the "other end" either.

As far as I have read nobody has discussed changing the config at the 
"other end", yours is the first mention of this.

---

From: Shane Amante <[email-masked]>
Date: Tue, 28 Sep 2010 14:56:38 -0600

Les,

> This does not change the operational config on another router - it only changes the config on the router on which the CLI command was issued. So this is hardly the same case. Similarly with the oth…

Let me try again, since I think we may be talking past each other.  Specifically, there's a big difference between the operational _config_ of a router and the operational _state_ of a router.  IME, the operational _state_ of the router matters substantially more than the operational _config_ of a router, given that the config doesn't always tell you what is currently happening on/to/through the device.  While a config may [sometimes] be a first source of information, it's not the _only_ source of information /nor/ a _definitive_ source of information -- if only that were the case, life would indeed be much easier for Ops!

With that said, please note that I did acknowledge (perhaps too tersely) that a change in priority is only reflected in the config on the current device, (but is only reflected in a _state_ change on the _old_ DIS/DR).  So, another Op on an adjacent device isn't aware of that change, (which is what I thought was your primary concern).  Let's look at the sequence of events a little more closely:
- t1: Op #1 is on router A that is DIS, due to either a default or manual priority setting, (say router A's priority is manually configured to be 100).
- t2: Op #2 logs into router B, set's its priority to be higher than than router A.  Router B, with priority = 120, is now DIS.
- t3: Op #1 on router A -- if they just look at the config -- will be completely unaware that router A's _state_ has changed so it is no longer DIS.  Op #1 should be flogged (repeatedly) if they _assume_ router A is still the DIS by only looking at the config on that box.

I don't see how this, or other examples I provided, differs substantially from the reverse-metric proposal.  Yes, reverse-metric is a /change in practice/ from what Ops folks have learned thus far; however, it's not vastly different from IS-IS overload bit or OSPF's stub-router advertisement.  In fact, I could easily tell it if reverse-metric was being applied and _where_ from anywhere in the network if vendor's implemented (or, operators enforced as a BCP) the setting of the reverse-metric to be infinity (2^32-1, since everyone uses wide-metrics).  Then, I can scan the IS-IS LSP DB for metric = infinity and know the LSPID if I wasn't aware that someone else had set this on a link in the network.  Of course, I need to take 1 more step and login to the "adjacent device" (found in the same LSP) that is _actually_ setting the high-metric on the link and hunt through the config for the reverse-metric command and delete it ... it's not that hard, really.

-shane

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 28 Sep 2010 15:04:23 -0700

Shane -

I think the difference can be clearly expressed in this way:

Router A Config
----------------
int eth 0/0
isis metric 20

Router B Config
----------------
int eth 0/0
isis metric 20

Both Router A and Router B behave in a manner consistent with the local
configuration i.e. they each advertise metric 10 to the pseudo-node for
ethernet 0/0.

(You could substitute "priority" in the above example if you like)

What is being proposed here is something like this:

Router A Config
----------------
int eth 0/0
isis metric 20

Router B Config
----------------
int eth 0/0
isis metric 20
isis reverse-metric 10000

This will cause Router B to send a new TLV indicating "reverse-metric
10000". When Router A receives that TLV it is expected to modify its
advertisements to reflect the reverse metric - so Router A is no longer
operating using its locally configured metric - instead it is operating
using the reverse-metric configured on Router B. 

The operational state is the same as if we went to Router A and changed
its metric configuration - but we used configuration on Router B and a
protocol extension to achieve that. This puts the routing protocol in
the business of changing configuration on its peers - I don't think we
should be doing that.

    Les

> Sent: Tuesday, September 28, 2010 1:57 PM
> Cc: Tony Li; [email-masked]; Mike Shand (mshand)
> >>> Yes - it could be done this way. But we are back to the model
where
> >> the
> >>> local configuration of Node A is overridden by TLVs sent from Node
> B
> >> -
> >> reflected in the "priority" CLI config cmd of the previous DIS or
DR
> > This does not change the operational config on another router - it
> only changes the config on the router on which the CLI command was
> issued. So this is hardly the same case. Similarly with the other
> examples you cite below.
> 
> Let me try again, since I think we may be talking past each other.
> Specifically, there's a big difference between the operational
_config_
> of a router and the operational _state_ of a router.  IME, the
> operational _state_ of the router matters substantially more than the
> operational _config_ of a router, given that the config doesn't always
> tell you what is currently happening on/to/through the device.  While
a
> config may [sometimes] be a first source of information, it's not the
> _only_ source of information /nor/ a _definitive_ source of
information
> -- if only that were the case, life would indeed be much easier for
> Ops!
> 
> With that said, please note that I did acknowledge (perhaps too
> tersely) that a change in priority is only reflected in the config on
> the current device, (but is only reflected in a _state_ change on the
> _old_ DIS/DR).  So, another Op on an adjacent device isn't aware of
> that change, (which is what I thought was your primary concern).
Let's
> look at the sequence of events a little more closely:
> - t1: Op #1 is on router A that is DIS, due to either a default or
> manual priority setting, (say router A's priority is manually
> configured to be 100).
> - t2: Op #2 logs into router B, set's its priority to be higher than
> than router A.  Router B, with priority = 120, is now DIS.
> - t3: Op #1 on router A -- if they just look at the config -- will be
> completely unaware that router A's _state_ has changed so it is no
> longer DIS.  Op #1 should be flogged (repeatedly) if they _assume_
> router A is still the DIS by only looking at the config on that box.
> 
> 
> I don't see how this, or other examples I provided, differs
> substantially from the reverse-metric proposal.  Yes, reverse-metric
is
> a /change in practice/ from what Ops folks have learned thus far;
> however, it's not vastly different from IS-IS overload bit or OSPF's
> stub-router advertisement.  In fact, I could easily tell it if
reverse-
> metric was being applied and _where_ from anywhere in the network if
> vendor's implemented (or, operators enforced as a BCP) the setting of
> the reverse-metric to be infinity (2^32-1, since everyone uses wide-
> metrics).  Then, I can scan the IS-IS LSP DB for metric = infinity and
> know the LSPID if I wasn't aware that someone else had set this on a
> link in the network.  Of course, I need to take 1 more step and login
> to the "adjacent device" (found in the same LSP) that is _actually_
> setting the high-metric on the link and hunt through the config for
the
> reverse-metric command and delete it ... it's not that hard, really.
> 
> -shane
> 
> 
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 29 Sep 2010 07:37:18 +0200 (CEST)

> the business of changing configuration on its peers - I don't think we 

Why not? We do that all the time, we have bgp inbound and outbound 
route-maps, all the examples Shane mentioned etc. This is done 
in a lot of places apart from metric of ISIS.

A stakeholder in a link should be able to influence both in and outgoing 
metric of a link. It is after all *part* of it. I can agree that having an 
outside nocd influence it would be weird, but having an actual participant 
influence how the other end handles what's seen through it, I think that's 
perfectly reasonable.

---

From: Tony Li <[email-masked]>
Date: Wed, 29 Sep 2010 00:03:20 -0700

On Sep 28, 2010, at 10:37 PM, Mikael Abrahamsson wrote:

>> The operational state is the same as if we went to Router A and changed its metric configuration - but we used configuration on Router B and a protocol extension to achieve that. This puts the routing protocol in the business of changing configuration on its peers - I don't think we should be doing that.
> 
> Why not? We do that all the time, we have bgp inbound and outbound route-maps, all the examples Shane mentioned etc. This is done in a lot of places apart from metric of ISIS.
> 
> A stakeholder in a link should be able to influence both in and outgoing metric of a link. It is after all *part* of it. I can agree that having an outside nocd influence it would be weird, but having an actual participant influence how the other end handles what's seen through it, I think that's perfectly reasonable.

Perhaps a more academic argument is that all of the members of an IGP are under a single administrative domain by definition anyway.  

If not, they have no business even forming an adjacency.

Tony

---

From: Erik Åman <[email-masked]>
Date: Wed, 29 Sep 2010 14:51:58 +0200

Hi,

I have been following this thread with great interest over the last 
couple of weeks. With the discussions lately surrounding arbitrarily 
adding to or subtracting from the metric configured in another router, I 
believe things may have gone a bit too far. There is obviously a strong 
difference in opinions and it simply seems that there is no chance of 
ever reaching an agreement. I would therefore like to ask the group to 
do a fresh start and bring us back to a discussion about the most basic 
version of this feature.

With experience from an operator network I support Mikael's original 
proposal -- there is an operational need for signalling that a link 
should be used only as a last resort. I also have enough insight into 
the IS-IS protocol to understand the concerns that in particular Les has 
expressed.

I would therefore suggest a renewed discussion limited to the following 
scope: Introduce a new TLV into the IIH packet that can only be used for 
setting the link metric to 2^24-2 (maximum usable metric) and maybe 
alternatively 2^24-1 (link to be excluded from SPF). The same mechanism 
would be used for both point-to-point links and multi-access media (in 
which case the DIS would advertise a non-zero metric from the pseudonode).

May I point out that a mechanism for signalling to an adjacent router to 
assign maximum metric on a link already exists in the form of LDP-IGP 
synchronization, RFC 5443. A hypothetical operator that does not need to 
use LDP could thus enable the protocol on all links and then disable it 
on a particular link just to signal to an IS-IS neighbour to avoid that 
link. (May only work on point-to-point links, though.) Having the option 
to instead signal this behaviour in the IIH packet doesn't fundamentally 
change the IS-IS protocol and is hopefully not much more difficult to 
implement.

As Tony has noted, this violates ISO 10589 since pseudonodes are 
supposed to have a metric of 0 to its neighbours. It is important to 
verify that deployed implementations do not actually assume all the 
pseudonode's metrics to be zero or treat a pseudonode LSP with non-zero 
metric as a malformed packet. Let me point out though that this would 
not be the first change that is incompatible with an implementation 
following ISO 10589 to the letter. Wide metrics is one such change that 
comes to mind. Some router vendors also give an option to ignore the ATT 
bit, something that could lead to routing loops if incorrectly deployed. 
In both of these cases we have stopped adhering to the original standard 
and anyone deploying these features needs to understand the consequences 
and ensure that the network is ready for it.

/Erik Åman

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 Sep 2010 06:55:54 -0700

What I am objecting to is not the functionality being discussed but the means of encoding/delivering it. It is proposed to define new IS-IS TLVs and carry information directly in IS-IS PDUs to set the configuration of IS-IS on another router. This is what I object to. This is the province of management applications and we should not be using IS-IS codepoints/PDUs to encode/carry this information.

Erik - in LDP-IGP sync the local router changes the metric it advertises for a given link based on local state - it does not do so at the direction of a remote node. The functionality you wish to achieve (advertising max-metric) is similar, but that is not what I am objecting to.

   Les

> From: Erik Åman [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2010 5:52 AM
> To: [email-masked]
> Cc: Mikael Abrahamsson; Les Ginsberg (ginsberg); Shane Amante; Tony Li;
> Mike Shand (mshand)

---

From: Erik Åman <[email-masked]>
Date: Wed, 29 Sep 2010 16:49:27 +0200

Les,

> What I am objecting to is not the functionality being discussed but the means of encoding/delivering it. It is proposed to define new IS-IS TLVs and carry information directly in IS-IS PDUs to set…

Yes, maybe we ought to use point-and-click tools in order to change the 
configuration at both ends of the link at the same time. The difference 
between theory and current practice has been described previously in 
this thread.

Also, this does not solve the issue of increasing the metric to one 
router from a LAN. The only thing any management application could 
accomplish with current IS-IS implementations would be to increase the 
metric from all routers to the LAN.

> Erik - in LDP-IGP sync the local router changes the metric it advertises for a given link based on local state - it does not do so at the direction of a remote node. The functionality you wish to a…

I've understood your point, but I also think there is a fine line 
between what is considered local state and what is directed from a 
remote node. An IS-IS adjacency today can a couple of different states. 
Upon receipt of a hello packet from a remote node with information in 
its TLVs that indicates that a three-way handshake has been completed, 
an IS-IS router transitions the adjacency to the "Up" state. That in 
turn triggers it to advertise the link in its LSP with a particular 
configured metric.

Let's say that we were to define an additional state "Unpreferred" with 
the definition that the adjacency should transition to this state upon 
receipt of a hello packet with particular TLV. Then we have suddenly 
turned it into a local state that causes the router to advertise the 
link with max metric.

/Erik

---

From: "iLya" <[email-masked]>
Date: Wed, 29 Sep 2010 17:59:08 +0200

(putting several things together)

I share Shane's view that it isn't NMS business (at least not today) to 
solve the problem we're discussing, so protocol modification seems 
reasonable place to look at. Also, I cannot agree with Les that proposed 
'reverse metric TLV' modifies config of another router, it should be better 
described as 'filling functionality gap' that exists in ISIS but solved e.g. 
in BGP - in BGP I can modify configuration of only my router, yet move 
traffic away from it in both directions even if I don't modify config of the 
peer(s).

There was proposal to put required functionality into Hello packet, but this 
is most likely not feasible because Hello packets may be not in the same 
processing path as LSP and glueing things together may become not trivial 
while gain (vs. carrying info where it belongs to - in LSP) is rather 
questionable.

Re-using LDP-IGP sync solution from rfc5443 doesn't seem suitable for making 
a link least preferred in both directions (as Mike initially asked for) but 
rather only in one. In fact introducing 'reverse metric TLV' will also help 
solving problem of LDP-IGP sync on multi-access networks.

Going through last mails it looks like 'reverse metric TLV' is the right way 
forward except for one potential obstacle on multiaccess subnets - we need 
to find out whether or not (majority of) current implementations will have 
problem with non-zero metric in pseudo-node LSP. Is there something we could 
do to move forward with this?

/iLya

---

From: Erik Åman <[email-masked]>
Date: Wed, 29 Sep 2010 19:12:57 +0200

> while gain (vs. carrying info where it belongs to - in LSP) is rather

I personally have no knowledge of how current IS-IS implementations are 
designed internally, but obviously there has to be a path from the 
process/thread/hardware handling the Hello packet exchange to the "main" 
part of the IS-IS process. If nothing else this is needed in order to 
inform the IS-IS process that the adjacency has timed out. In the 
operational scenario described we don't need things to change on 
millisecond timescales. It may even be acceptable that the higher metric 
does not get deployed until a full hello packet hold time has passed, if 
that's what it takes.

To me it seems that doing this at the Hello packet level is the most 
natural, since that's where the awareness of individual links exists. If 
doing a "reverse metric TLV" part of the LSP, remember that you will 
need to identify the individual link whose metric should be changed. In 
that context, don't forget that there may be multiple parallel links 
between two routers, only one of which has bit errors.

 From my point of view I don't care about the exact details of the 
implementation. If your approach turns out to be more feasible I have 
nothing against seeing it deployed. I suggested using a TLV in the Hello 
packets (and perhaps introducing an additional adjacency state) because 
that seemed to me to be more straight-forward and therefore easier to 
implement.

/Erik

---

From: Mach Chen <[email-masked]>
Date: Thu, 30 Sep 2010 17:01:35 +0800

Hi Les,

....
> the business of changing configuration on its peers - I don't think we

But the similar mechanisms have already proposed/defined in BGP 
protocol(e.g., the BGP ORF(Outbound Route Filter) and RT-constrains 
functions, filtering rules configured in one router, but used on other 
router(s)). IMHO, this should not be the reason to prevent doing such 
"reverse metric" TLV extension if this function is useful and desired. And 
seems that you also think this function is useful :-) (at least not object 
to).

Best regards,
Mach

---

From: shengcheng <[email-masked]>
Date: Thu, 30 Sep 2010 17:52:20 +0800

Mikael,

I  think it definetly will bring benefit to carriers if isis can be extended to solve the issues you proposed. 

But my concern is:

1, For p2p, 

In/out metric you defined and the improved mechanism Tony is really impressive.
While in my view, new concepts and technique will add new complexity for the coding engineer and the matenence people(need to understand and implement it corretlly).
As the benefit is not so big i think, i prefer to improve the current management tool to solve it w/o changing the isis protocol.

2, For ethernet,  

First of all, i doubt is this a common scenario that most of  Carriers meet? To my experience, isis is often deployed in the IP backbone network.
To achieve high routing convergence performance, most carriers deploy p2p on POS(or p2p over Ethernet) link to build their network.
If i am right, the issue is a rare scenario...

Second, as Tony told , no existing solution can solve the issue, and we have to make modificaiton to ISIS protcol.
This will be a more complex change for isis protocol than 1, which will impact the exisiting basic ISIS ethernet LSDB model .
So i am not sure if the benefit is up to the efforts we pay.

Anyway,  I think you proposed two valueable issues from reality, though it take some time for all to understand it accurately.
:)

Victo Sheng

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Sep 2010 15:32:10 +0200 (CEST)

On Thu, 30 Sep 2010, shengcheng wrote:

> While in my view, new concepts and technique will add new complexity for 
> the coding engineer and the matenence people(need to understand and 
> implement it corretlly).

If you by "maintenance people" mean the people operating a network, it has 
so far taken me approx 2 minutes per person to explain the feature (bidir 
metric on ptp links) to the operational staff, they usually have a few 
questions and then light up and say, "ah, that's great! When can we have 
it? Give me!". It's not a complicated concept, quite the opposite.

Yes, we do not use a lot of management systems to configure the network 
and we don't really want to start either.

> First of all, i doubt is this a common scenario that most of Carriers 
> meet? To my experience, isis is often deployed in the IP backbone 
> network. To achieve high routing convergence performance, most carriers 
> deploy p2p on POS(or p2p over Ethernet) link to build their network. If 
> i am right, the issue is a rare scenario...

We've been running ISIS on LAN since 1999 when we switched away from 
EIGRP. Yes, we run it on POS/ptp ethernet as well. We're moving away from 
LANs partly because of the metric issue, instead we waste IP addresses by 
creating p-t-p links over vlans.

---

From: Tony Li <[email-masked]>
Date: Thu, 30 Sep 2010 08:43:32 -0700

> If i am right, the issue is a rare scenario...

There are a number of carriers who use switches as POP aggregation devices.  

Tony

---

From: shengcheng 00129664 <[email-masked]>
Date: Fri, 01 Oct 2010 08:46:57 +0800

Mikael,

> and we don't really want to start either.

I agree with you that this is an easy-understood method. 
While even the rule is simple, it is a new one and add new possibility of errors(bugs or misconfiguration etc).
Above all, i think management tool is much easier solution for p2p situation which you dislike.:)

Anyway, allow me go to another basic issue: What is the purose of link metric of ISIS?
As i start learning IGP protocol, i know metric value of a link reflect the bandwidth capability of 
the link and used to direct the traffic choose the shortest path.
The higher the bandwidth of the link, the lower the metric of the link should be.
It is somewhat "unfeasible" if the metric of a 10G link is bigger than a 1G link in one ISIS network, 
and so does two end nodes of the same link have different metric value of your scenario? 
So let's consider another way to solve your issue: It is permitted to configure differnet metric for the same link from the two sides, 
while when routers do route calculation, the bigger metric of a link will always be chosen during two-way check of SPF computation. 
If so, nothing need to be changed but a small modification for the SPF implementaion(no new concept, no new TLV..)..

Of course, this doesn't work for your ethernet case.

---

From: shengcheng 00129664 <[email-masked]>
Date: Fri, 01 Oct 2010 08:48:56 +0800

Hi Tony,

It is expected some more carriers could join this discussion and express their consideration.

Victo Sheng

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: Tony Li <[email-masked]>
Date: Thursday, September 30, 2010 11:43 pm
Subject: Re: [Isis-wg] operational problem might be solved bysomehowextending current IS-IS
To: shengcheng <[email-masked]>
Cc: Mikael Abrahamsson <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, [email-masked], "Mike Shand (mshand)" <[email-masked]>

> 
> > First of all, i doubt is this a common scenario that most of  
> Carriers meet? To my experience, isis is often deployed in the IP 
> backbone network.
> > To achieve high routing convergence performance, most carriers 
> deploy p2p on POS(or p2p over Ethernet) link to build their network.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 1 Oct 2010 08:15:52 +0200 (CEST)

> the link and used to direct the traffic choose the shortest path.

That's up to each ISP to decide. We have a latency component in ours, it 
doesn't only reflect bandwidth. So within the "pool" of 10G links, due to 
us measuring the latency over each link, we make the traffic take the 
latencywise shortest path within that pool, but we also add a big number 
on slower links to it to make sure through 10G traffic doesn't traverse a 
latencywise shorter 1G link.

> So let's consider another way to solve your issue: It is permitted to 
> configure differnet metric for the same link from the two sides, while 
> when routers do route calculation, the bigger metric of a link will 
> always be chosen during two-way check of SPF computation. If so, nothing 
> need to be changed but a small modification for the SPF implementaion(no 
> new concept, no new TLV..)..

There is nothing that stops oneself from configuring different metrics at 
each end, we do that in some cases.