headers
shengcheng 00129664 | 1 Oct 2010 02:46
Favicon

Re: operational problem might be solved bysomehowextending current IS-IS

Mikael,

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

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
shengcheng 00129664 | 1 Oct 2010 02:48
Favicon

Re: operational problem might be solved bysomehowextending current IS-IS

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 <tony.li <at> tony.li>
Date: Thursday, September 30, 2010 11:43 pm
Subject: Re: [Isis-wg] operational problem might be solved bysomehowextending current IS-IS
To: shengcheng <shengc <at> huawei.com>
Cc: Mikael Abrahamsson <swmike <at> swm.pp.se>, "Les Ginsberg (ginsberg)" <ginsberg <at> cisco.com>,
isis-wg <at> ietf.org, "Mike Shand (mshand)" <mshand <at> cisco.com>

> 
> > 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...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikael Abrahamsson | 1 Oct 2010 08:15
Picon
Favicon

What is metric (was: Re: operational problem might be solved bysomehowextending current IS-IS)

On Fri, 1 Oct 2010, shengcheng 00129664 wrote:

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

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.

--

-- 
Mikael Abrahamsson    email: swmike <at> swm.pp.se
Permalink | Reply | 0 comments |
headers
guan | 1 Oct 2010 09:11
Picon

Re: operational problem might be solved bysomehowextending current IS-IS


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

I would say this is very common scenario in SP and we do have this setup in our network as well.

Guan
Permalink | Reply | 1 comment |
headers
Suri, Simranjyot (Simranjyot | 4 Oct 2010 21:42
Favicon

Re: operational problem might be solved bysomehowextending current IS-IS

Hi All,
I've been following this discussion for a while now and it's turning out to be an extremely interesting and
important one. I'd like to make a few comments and hopefully have everyone look at the issue from a slightly
different perspective.

Shane and Mikael,
The issues that you've brought up are very important indeed, and it would be good to get solutions for them
from the protocol itself (if reasonably possible). I completely empathize with your plight -- being
paged in the middle of the night (2:00 am?!) and having to debug a live customer issue after dragging
oneself out of bed is no fun (to put it mildly), and you need the best tools possible! :) 
To recap briefly, the requirements that you're seeking are:
1. Instead of having the entire IS/router (router from now on) go into overload, have a mechanism for a
router to isolate a specific link (p-to-p or broadcast) in BOTH directions
2. Same as 1 except have a mechanism for a router to change the metric for a specific link (p-to-p or
broadcast) in BOTH directions to MAX_METRIC (so that the link can be used in case no other link/path is available)

Since people have already suggested acceptable solutions for the first point, I'd like to address the
second one. Essentially, it seems like all that is being sought here is a type of "overload-link"
mechanism from the IS-IS protocol. As Ilya, Tony and others have correctly pointed out, there are
multiple ways to solve this issue, but of course ALL of these will require a protocol extension of some sort
(i.e. ALL routers at a particular level would have to support the proposed changes). 

The proposal involving a 'reverse-metric' TLV in a Hello packet, which in turn causes the neighbor to
increase its own metric, is an interesting one and is definitely very intuitive and easy to understand. It
has the following characteristics:
a) It needs a protocol extension to support non-zero DIS metric and a corresponding change in SPF
- This is not an issue per-se, since a protocol extension of some form will anyway be needed if the
requirements need to be satisfied
b) Protocol no longer remains purely distributed, since one router's advertised information causes a
change in the neighboring router's advertised information
(Continue reading)

Permalink | Reply | 0 comments |
headers
Les Ginsberg (ginsberg | 7 Oct 2010 07:45
Picon
Favicon

Nits in draft-shen-isis-oper-enhance-00.txt

(As the subject says - all nits)

Section 1.2 second sentence:

s/ through cumbersome/ though cumbersome

Section 2 second paragraph

s/ the IS to IS Hello (IIH) message used/ the IS to IS Hello (IIH)
message is used

Section 3.1 first sentence

"A further simplification is to allow any system to temporarily become
   the DIS, when it is directed to, and set a non-zero metric in the
   pseudonode."

Could this be rewritten as:

"An alternative is to allow any system to temporarily become
   the DIS, when it is directed to, and set a non-zero metric in the
   pseudonode LSP(s)."

I am not convinced this is really "simpler" than the solution in Section
3. Whether changing the priority and then setting metrics is simpler
then knowing who the DIS is and setting metrics is arguable - and
certainly changing the DIS as well as changing metrics is more
disruptive to the network (more LSP churn). Rather than debate this, the
revised text describes this as an alternative w/o passing judgment.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Les Ginsberg (ginsberg | 7 Oct 2010 07:56
Picon
Favicon

draft-ietf-isis-ieee-aq-00.txt comments

In several places there are references to new sub-TLVs in TLV 222 (MT IS
Neighbor) - but TLV 22 is never mentioned. This differs from the
presentation in draft-ietf-isis-layer2-05 - the last version before the
different L2 technologies were split into separate documents and also
differs from current convention where all sub-TLVs that may appear in
TLV 22 may also appear in TLV 222. It also suggests that you are
intentionally ruling out the use of MTID #0 (legacy topology).

Is this deliberate or an oversight?

   Les
Permalink | Reply | 1 comment |
headers
Naiming Shen | 7 Oct 2010 08:12
Picon
Favicon

Re: Nits in draft-shen-isis-oper-enhance-00.txt


Les,

thanks for the comments.

On Oct 6, 2010, at 10:45 PM, Les Ginsberg (ginsberg) wrote:

> (As the subject says - all nits)
> 
> Section 1.2 second sentence:
> 
> s/ through cumbersome/ though cumbersome
> 
> Section 2 second paragraph
> 
> s/ the IS to IS Hello (IIH) message used/ the IS to IS Hello (IIH)
> message is used
> 
> Section 3.1 first sentence
> 
> "A further simplification is to allow any system to temporarily become
>   the DIS, when it is directed to, and set a non-zero metric in the
>   pseudonode."
> 
> Could this be rewritten as:
> 
> "An alternative is to allow any system to temporarily become
>   the DIS, when it is directed to, and set a non-zero metric in the
>   pseudonode LSP(s)."
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shane Amante | 14 Oct 2010 04:56

Fwd: I-D Action:draft-amante-isis-reverse-metric-00.txt

Hi,

Per a discussion on the mailing list last month, spurred by Mikael, here's a first attempt at a proposal to
enable the bidirectional changing of an IS-IS link metric in order to gracefully remove a link from the
topology during network maintenance events.  Comments are welcome.  

-shane

Begin forwarded message:
> From: Internet-Drafts <at> ietf.org
> Date: October 13, 2010 8:45:02 PM MDT
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-amante-isis-reverse-metric-00.txt 
> Reply-To: internet-drafts <at> ietf.org
> 
> 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-00.txt
> 	Pages           : 11
> 	Date            : 2010-10-13
> 
> 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.
(Continue reading)

Permalink | Reply | 6 comments |
headers
iLya | 14 Oct 2010 13:51

Re: Fwd: I-D Action:draft-amante-isis-reverse-metric-00.txt


--------------------------------------------------
From: "Shane Amante" <shane <at> castlepoint.net>
Sent: Thursday, October 14, 2010 4:56 AM
To: "isis mailing list" <isis-wg <at> ietf.org>
Subject: [Isis-wg] Fwd: I-D Action:draft-amante-isis-reverse-metric-00.txt

> Hi,
>
> Per a discussion on the mailing list last month, spurred by Mikael, here's 
> a first attempt at a proposal to enable the bidirectional changing of an 
> IS-IS link metric in order to gracefully remove a link from the topology 
> during network maintenance events.  Comments are welcome.
>

Shane,

a paragraph in Section 2 reads:

"   The Metric field may be a "default metric", in the range of 0-63, or
   a "Traffic Engineering Default Metric" [RFC5305] "

You've probably ment "Default metric" of TLV 2 or "Default metric" of TLV 22 
(and not TE Default Metric). Additionally, it would be nice to cover IPv6 
metric (RFC5308) if multi-topology is used using sub-TLV as you did for TE 
Metric.

Also, the draft should probably spell out what a receiver should do if it 
receives reverse metric >63 but the node itself is not configured to use TLV 
22 (though I don't know if there are any networks left that still use
(Continue reading)

Permalink | Reply | 1 comment |

Gmane