Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 20 August 2008 10:10 UTC

Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100393A6BD6 for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 20 Aug 2008 03:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.869
X-Spam-Level:
X-Spam-Status: No, score=0.869 tagged_above=-999 required=5 tests=[AWL=-1.237, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N7oeM5cfwOk for <ietfarch-ccamp-archive@core3.amsl.com>; Wed, 20 Aug 2008 03:10:16 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A4943A6B81 for <ccamp-archive@ietf.org>; Wed, 20 Aug 2008 03:10:16 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KVkW6-000FtV-7Z for ccamp-data@psg.com; Wed, 20 Aug 2008 10:02:14 +0000
Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1KVkW1-000Fr0-Jc for ccamp@ops.ietf.org; Wed, 20 Aug 2008 10:02:11 +0000
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7KA236n030979; Wed, 20 Aug 2008 11:02:03 +0100
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7KA22iV030958; Wed, 20 Aug 2008 11:02:02 +0100
Message-ID: <039501c902ab$cae9c170$0300a8c0@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: tony.li@tony.li
Cc: 'Dan Li' <danli@huawei.com>, 'Igor Bryskin' <i_bryskin@yahoo.com>, Snigdho.Bardalai@us.fujitsu.com, ccamp@ops.ietf.org
References: <563325.51910.qm@web36801.mail.mud.yahoo.com> <30CDDADB3BE248069E16208195D56458@ad.redback.com> <03e101c90273$0dd3aac0$394d460a@china.huawei.com> <F860A724514E4030A156FC519AB41114@ad.redback.com>
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'
Date: Wed, 20 Aug 2008 11:01:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>

Hi Tony,

(and by the way, welcome to CCAMP)

>> 1) The amount of information advertised
>> The amount of information carried and the stability of that information 
>> is
>> similar to that used in TE networks today. In those networks, when a TE 
>> LSP
>> is set up or torn down, there is a change in the bandwidth availability 
>> on
>> all links traversed. This causes an update to the TE information 
>> advertised
>> in the IGP for those links.
>
> True.  However, typically the number of TE LSPs that are established is a
> static number.  Even in extreme cases, folks typically use O(n^2) LSPs to
> form a complete mesh of their nodes.
>
> In the applications that I think that you're contemplating, there are many
> more links, with the ability of end users to set up their own links
> throughout the network.  Please correct me if I'm misunderstanding.

I think there is some misunderstanding here.
It is true that in a private lambda model, the end-user may request the 
establishment of the LSP (where the end-user might be a packet network), but 
I don't think we should assume that the connectivity is worse than that in a 
TE network. Indeed, it is likely to be much less. This is in part due to the 
expense of equipment, the topology of the network, and the constraint of the 
number of lambdas supported on any link. That means that a single PE will 
only connect to a realtively small number of other PEs.

Of course, this may vary in time as technology improves and as networks get 
larger and have greater use.

>> In general, this is not seen as a critical issue. There are several
>> possibilities to reduce the impact of TE advertisements if they become a
>> problem. For example, as implemented in some of our current IP network, 
>> each
>> router can impose a threshold (time and/or bandwidth delta) before which 
>> it
>> will not re-issue an advertisement.
>
> Effectively rate limiting the link state database flooding, which is the
> goal.
>
>> In networks that require IGP convergence (for IP data traffic) and TE
>> advertisement (for MPLS-TE traffic) there is some concern that the
>> distribution of TE information might impact the IGP convergence time. In
>> these cases, implementations may prioritise normal LSAs ahead of opaque
>> LSAs, or may use separate protocol instances.
>
> The former is more difficult in IS-IS, as TE information is typically
> distributed as part of the same LSP that carries the physical link
> information.  Separate protocol instances is of course possible, but it
> would seem like it would become more of a manageability issue (do you need
> identical topologies?) and would not obviate the need for CPU cycles.

Yes. The Gen-App work in IS-IS is specifically to address this issue, I 
believe. CPU cycles will remain an issue for everyone. But if you build a 
box for a specific environment, you had better buiold a big enough box!

>> 2) Speed of convergence of wavelength availability
>> In a TE network, the need for an up-to-date TED depends to a good degree 
>> on
>> the relative size of LSPs and residual bandwidth, and on the rate of 
>> arrival
>> of new LSPs. Increasingly, core TE LSPs may be quite large, but in 
>> general,
>> the rate of arrival of large LSPs is quite low, and the holding times are
>> quite high.
>>
>> So, the bottom line in a TE network is that when an LSP needs more 
>> bandwidth
>> than is actually available, it is crucial that the TED is up-to-date (or
>> "real-time" like some folks may call it).
>
> I'm not sure that I would characterize it as 'crucial'.  It would seem 
> like
> there is always going to be *some* window where remote nodes have 
> imperfect
> information, just due to speed of light delays.  Ergo, the head end must
> always be prepared for its path to be rejected during setup and then
> recompute the path based on new information.

Absolutely.

And the signaling protocols are specifically designed to handle this case.

Nevertheless, for customer experience (TM) we would hope to make this window 
relatively small.

And, indeed, the debate lower down the email is really about how likely we 
are to fall through the window. If it happens for every LSP setup attempt, 
something clearly needs to be done in the protocols. If it happens less than 
1% and only in really busy networks, this may be acceptable.

>> But as Igor has pointed out, this is impossible to achieve in a 
>> distributed
>> system. Indeed, it is impossible to achieve even in a centralised system
>> since network failures may occur. That means that there is always a
>> possibility that a computed path will be signaled and will fail to be
>> established. We should be familiar with this situation in scenarios such 
>> as
>> contention during restoration after network failure, and the signaling
>> protocols are designed to fail and try again (usually using "crankback"
>> information about the failed link, but also assuming that the IGP may 
>> have
>> converged in the mean time).
>
> Note that crankback (recomputing the path DURING setup) is not always
> necessary.  Sometimes recomputation at the head end will suffice.

Yes. It all depends on whether the TED has converged in the mean time. If 
so, then reporting the failure and triggering recomputation is needed. If 
not (or if you can't be sure) it is best to recompute with the knowledge of 
which link caused the failure in the original setup. That's crankback (RFC 
4920).

>> We can look at a couple of things:
>> - What is the arrival rate of lambda LSPs?
>> - What is the required setup time of lambda LSPs?
>>
>> With the exception of restoration LSPs, I think we may say that a 5-10
>> second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but 
>> you
>> may have a different experience.
>
> In my experience nearly static LSPs are perfectly acceptable, and setup 
> time
> is not an issue.  ;-)

Exactly.

What we find at the moment, however, is that there is a lot of discussion 
about moving the transport network from a "nearly static" animal to 
something that is semi-dynamic, or even "on-demand".

This changes the boundaries, but it is still not clear to me that 
"on-demand" means sub-second as I would expect all lambda LSPs to go through 
a testing phase before being put in service (even if this is an automatic 
phase). And I would expect such a phase to take a number of seconds.

That said, restoration is a different question.

> My concern however is simpler: limiting the rate of link state database
> flooding.  This is vital to ensure the stability of the IGP.

Agreed, but let's be careful to understand the size of the network, the 
amount of information, and the rate of change of that information. This is 
really what Dan's I-D is starting to look at, so contributions to helping 
with that understanding are welcome.

If, as you say, most of these LSPs are nearly static, we obviously don't 
have to worry about the amount of flooding. It is only when LSPs come and go 
(or when nodes/links come and go) that we will see a change in flooding. I 
think that what Dan said in this email points out that the amount of 
flooding (but not necessarily the amount of information flooded) is similar 
to what we already see in TE networks. We should certainly look to see what 
the stability experience is with those networks - my understanding is that 
they are deployed and functional.

Cheers,
Adrian