|
Hi Tony, Igor,
I think we should separate two points for this discussion.
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.
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.
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.
Note that in WSON networks the only
likely use of the IGP except for TE/RWA information is for the DCN. In this
case, distinguishing the two convergence times is less of a
concern.
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).
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).
As Igor also points
out, the situation in RWA is slightly more sensitive because a lambda is either
there or not. Actually, this situation is just the same as the marginal
bandwidth problem just desribed for TE networks. Since lambda availability
information cannot be distributed instantly, there is always the chance that a
computed path will fail because the lambda is not actually available. In the
case of multiple points of computation, there is always the chance of contention
for a lambda and so we must accept that some LSP setup attempt will fail -
again, crankback and recomputation will normally ease the situation.
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.
Regards,
Dan
----- Original Message -----
Sent: Tuesday, August 19, 2008 3:43 AM
Subject: RE: Comments on
'draft-li-ccamp-wson-igp-eval-01.txt'
Igor, Dan,
Perhaps there's
an important distinction to be made here. Typically, having an IGP carry
lambda connectivity status isn't a significant issue, as that should
only change when there is a significant failure. Debouncing techniques
should be used to prevent any connectivity
oscillations.
However, carrying lambda utilization status in the
IGP is not going to prove practical, as the continued series of updates would
easily lead to IGP thrash if done at anything approaching real-time.
Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1
minute) is probably not an issue for networks of reasonable scale. This
of course won't match many folks' requirements for
'real-time'.
Tony
Dan,
That's the point. How does PCE maintain the lambda
availability status? PCE architecture shyly puts this problem out of its
scope, but the only known way today for the PCE is to participate in one or
more IGP-TEor BGP-TE routing protocols. So, in this respect it does not
matter whether paths are computed locally or via PCE
service.
Igor
-----
Original Message ---- From: Dan Li <danli@huawei.com> To: Igor
Bryskin <i_bryskin@yahoo.com>; adrian@olddog.co.uk;
Snigdho.Bardalai@us.fujitsu.com; ccamp@ops.ietf.org Sent: Friday, August
15, 2008 1:55:04 AM Subject: Re: Comments on
'draft-li-ccamp-wson-igp-eval-01.txt'
Hi Igor,
You're right, when we doing the path computation, the TE link
lambda available status should be precise and real time updated. If we do
the path computation in distribute way, this would be a big problem because
of the TE link lambda available status may not be updated right away. But we
can do it in centralized way to minimized this problem. For example, using
PCE and if the PCE can maintain the TE link lambda available status, this
may not be a problem because all the path computation requests are in the
queue of PCE, and PCE knows which lambda is available.
Regards,
Dan
----- Original Message -----
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on
'draft-li-ccamp-wson-igp-eval-01.txt'
Hi,
Please, see my comment in line. Look for
IB>>
Cheers,
Igor
-----
Original Message ---- From: Adrian Farrel < adrian@olddog.co.uk> To: Snigdho.Bardalai@us.fujitsu.com;
ccamp@ops.ietf.org; danli@huawei.comSent: Monday,
August 11, 2008 1:24:50 PM Subject: Re: Comments on
'draft-li-ccamp-wson-igp-eval-01.txt'
Hi,
I have the following comments on this draft. I was wondering what
were the objectives for the IGP evaluation. IMHO the evaluation from
WSON perspective should address the following:
1. IGP usage in the
context of traditional distributed solutions for WSON
[Dan] With the situation that TE information is already be
carried by IGP, it's nature to think that the wavelength information can
also be carried by IGP. I am not saying it should be, but it's worth to
look at.
IB>> There is an important difference in
requirements for advertising of TE link information vs. advertising TE
link lambda availability. When OSPF TE speaker advertises TE link info
it, apart from link statical information, is pretty much saying : "I
have 70% of bandwdith availbale on priority p". For the path computer
(say, PCE) it is almost always not important if the link has actually
75%, 70% or 60% of available bandwidth. However, lambda availability
(like pregnancy) is boolen: either it is there ot it is not. PCE which
perfoms path computation in terms of lambdas, unfortunately. must have
almost momentarily lambda availability states. With the speed of TE info
flooding current IGP-TE protocols have to offer, such mechanism will not
work on dynamic networks. And in any case one can never rely on PCE
during recovery path computations. These limitations. I think, should be
clearly stated in the document.
[Bardalai, Snigdho] Do you see any particular issues with
using the IGP for this purpose ?
[Dan] From the result of the
simulation, the OSPF convergency time takes a liitle bit
longer when the entire network restarts. Because the WSON
information is added in the OSPF LSA. During the network running
normally, the update of wavelength availability
information doesn't impact the IGP performance
obviously.
[Adrian] Certainly, from the point of view of
someone coming at this without an implementation (I used to have
one :-), the concern is that adding the RWA information to the IGP might
mean that there was simply too much information to be distributed. What
Dan's draft is trying to do is show the dimensions of the information
and how dynamic it is. From this, we can quickly see how things
will scale.
I do not believe that there
is an issue with the interaction with IP routing, but I guess we should
consider that it is possible that the DCN will be a real IP network
carrying other traffic and that we need to not disrupt IGP convergence
in that network. Mechanisms exist (or are being developed) to make that
safe, and Dan's I-D should be able to tell us how important it is to use
them.
2. IGP usage in the context of PCE
solutions for WSON
[Dan] It's a potential way for
PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where
path-computation takes place is it possible to limit LSA advertisements
from PCC to PCE neighbors, instead of to every PCC
neighbor?
[Dan] You are right, PCC which doesn't do the
path-computation doesn't need this kind of information.
[Adrian] This is an
important point which you raised in conversation with me in Dublin: it
is possible to consider using link-local scope flooding of RWA
information from PCC to PCE so that it goes no further. But there is a
clear trade-off... with how many PCCs will a PCE be required to maintain
an IGP association? There is also a quesiton to be answered about the
function required for restoration - how much information does the
head-end LSR need to perform rapid, "best-effort" path computation to
restore LSPs after a network failure? This information *does* need to be
flooded. The informaiton model I-D is intended to help with this
question.
3. Flooding and refresh of static and
dynamic link state updates
[Dan] Try to figure
out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of
static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to
reduce the protocol traffic. But we should consider the scenario when a
node gets restart or goes down, so the HELLO message may still need to
be kept.
[Adrian] Yes. You are both
right. We should treat "static" as truely static and not needing
refresh. We can handle node-down and link-down events without the need
to time out the LSAs containing the static data if we link the behavior
to the time-out of other node/link information. But we *do* need to
consider the amount of information that will be held in LSA DBs and need
to be flooded at start of day and in node restart as
below.
4. Data base sync-up during node
restarts
[Dan] Yes, this should be considered.
Especially the very large amount of data will be sent to the restarting
node. We may consider the point to point data exchange instead of
flooding the LSA updates. Or slice the big data packet into small
pieces.
[Bardalai, Snigdho] This is little
tricky, I would be interested to see if there is a clean
solution.
[Adrian] An important point to consider (in
OSPF) is what happens in a lossy environment if the LSA gets very large.
In this case it will be fragmented into very many IP packets and there
will be a good statistical likelihood of at least one packet being lost.
That means that the LSA might never get delivered whiled the DCN will
get hammered. One solution (thanks, Igor) is to break the information
down into smaller LSAs. Since the information is essentially lists or
matrices, this is quite easy to do.
Could you please let me know if the
above is within the current scope? I believe that these are important.
[Adrian] Very much in scope!
Cheers,
Adrian
|