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