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