Subject: RE: [NSIS] state management and the nsis framework

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 15 May 2003 14:27:43 +0200

Hi Georgios,

To repeat:

G| If a NTLP state is not refreshed in time the NSLP instance 
G| is informed about it. Otherwise the NSLP instance 
G| assumes that the NTLP state is alive.

R|   +---C---+
R|  /         \
R| A-----------B

R| Assume A, B, C to support NTLP, whereas the NSLP of interest is only 
R| supported by A and B. Once the link A-B is broken, the NTLP A-B
R| isn't refreshed while the NSLP A-B could easily maintain state 
R| via A-C-B communication.

G|...yes, it is of no
G| importance to the NSLP B that NTLP B lost connectivity to NTLP A.

I'd like to come back to my question: Could you kindly tell me how your
system reacts in this case? 

G| I tried to emphasize that the network configuration example
G| that you used, in many situations cannot be considered as a
G| network configuration applied in NSIS.

Could you provide a refernce to an NSIS WG document with the network 
configurations to be applied by NSIS in most situations?

Regards, Rüdiger
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 15 May 2003 15:22:32 +0200

Hi Ruediger

[RG]
> system reacts in this case?

[GK]
If I would assume that the network configuration in your example is a
realistic one and that it can be considered as a generic network
configuration used in NSIS then:

Assuming that the link (A)<->(B) fails, and
If the re-routing time is higher than the refresh timer used by the
NTLP protocol at node (B) then the NTLP and  NSLP states
could be tear down. If the re-routing time is less than the refresh timer
used by the
NTLP  protocol at node (B) then the NTLP and NSLP states
could be maintained.
However, if due to the failure at link (A)<->(B) the NTLP and NSLP state at
node (B)  are tear down,
then the NTLP and NSLP states at node (B) will be re-initiated after
re-routing.
---------------------------------------------

[RG]
> Could you provide a reference to an NSIS WG document with the network

[GK]
The network configuration to be applied by NSIS in most situations is
a generic Internet architecture, where path coupled signaling is used
to route NSIS signaling messages. Meaning that in most situations the path
that is
followed by NSIS signaling messages
is defined by a typical dynamic routing protocol.
Such a situation is depicted in the example that I provided.
----------------------------------

If I understood you correctly,  you try to say that a route change will
mainly affect the NTLP soft
state management and not the NSLP soft state management.
What I am trying to say is that in many situations a route change will
affect both NTLP and NSLP
soft state management procedures.

Best Regards,
Georgios

---

From: Tom Taylor <[email-masked]>
Date: Fri, 16 May 2003 11:18:06 -0400

Georgios' example raises this question: is NTLP used to maintain the path between 
successive NSLP nodes, or is it used to maintain an end-to-end path which may 
traverse a variable set of NSLP nodes as a result of rerouting activity.  If the 
latter is the case, the implication for NSLP is that there has to be a way to bring 
a new NSLP node into the picture (i.e. provide it with all the necessary state) 
quickly and also to clear state from NSLP nodes dropped from the path.

Just to restate my point: does NTLP control which NSLP nodes are in the end-to-end 
path, or does NSLP (i.e. the specific signalling application) do so?

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Mon, 19 May 2003 12:35:38 +0200

Hi Tom Taylor,

It's clear that NTLP only has the scope on its peer-relation (the NSIS
adjacent entity and there is no other NEs between).  NTLP is the means for
NSLP to establish the E2E signaling on peer-relation.

According to me, Georgios' example is an one of the general case : there is
a change of topology (change of routing table, interruption, mobile...).

regards

Nary Tra
ENST, Paris
Tel (0033) (0)1 45 81 71 06.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 20 May 2003 14:14:11 -0400

I think the consequences of what you're saying are that if there is a change of 
topology at the transport level:

1) at each node where the NSLP application is present, NTLP must notify the NSLP 
application that a change has occurred.  I assume indications of change are 
propagated between NTLP nodes along the path, so NTLP nodes remote from the point of 
change are aware of the change;

2) it is up to the NSLP application to reestablish topology at its own level;

3) contrary to what George has been proposing, it is therefore not possible to 
expect NTLP to refresh NSLP soft state.

Thanh Tra LUU wrote:
>>Georgios' example raises this question: is NTLP used to maintain the path
> 
> between
> 
>>successive NSLP nodes, or is it used to maintain an end-to-end path which
> 
> may
> 
>>traverse a variable set of NSLP nodes as a result of rerouting activity.
> 
> If the
> 
>>latter is the case, the implication for NSLP is that there has to be a way
> 
> to bring
> 
>>a new NSLP node into the picture (i.e. provide it with all the necessary
> 
> state)
> 
>>Just to restate my point: does NTLP control which NSLP nodes are in the
> 
> end-to-end
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 21 May 2003 09:48:23 +0200

Hi Tom

Please note that the data path is using for routing,
typical dynamic routing protocols, e.g., OSPF.
In a path coupled signaling protocol, (i.e.,
on-path signaling protocol) the signaling protocol has to actually use
the same (on a coupled manner) path as the path used by the
data path.
This means that the NSLP protocol cannot change the network topology that
is used by the data path.

Best Regards,
Georgios

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 21 May 2003 13:40:28 +0200

Hi Tom Taylor,

> change are aware of the change;

Yes, NTLP notifies NSLP that a change has occurred. Please note that, there
can be a lot of  different NSLPs on a NTLP, so I think it can notify only
some NSLPs.

------------                                      ----------
|   NSLP   |                                     |   NSLP   |
-----------         ------------             ----------
|  NTLP   |  == |   NTLP   | ===== |    NTLP  |
-----------        -----------              ------------
            <------                <--------

   A                      B                            C.

Even though B is not a NSLP-aware, the indications of change are still
propaged to A.

> 2) it is up to the NSLP application to reestablish topology at its own
level

I don't know what the word reestablish topology means, do you mean
reestablish a new signalling route ? If you mean reestablish a new
signalling route, I think that's better if it's up to NSLP.

> expect NTLP to refresh NSLP soft state.

Yes, I think so.

regards

 Nary Tra
ENST, Paris

---

From: Tom Taylor <[email-masked]>
Date: Wed, 21 May 2003 08:29:33 -0400

As I see it, there are two topologies: the sequence of NTLP nodes can be 
distinguished from the sequence of NSLP nodes for a particular application. 
Obviously these are linked, but to the extent that you can have intervening NTLP 
nodes that do not also support the particular NSLP application, the NTLP topology 
can change while leaving the NSLP-level topology intact.  For this to happen, NTLP 
would have to have maintenance of the NSLP topology as an explicit goal.  That is, 
in the event of a break, NTLP searches for an alternate route to the next NSLP node, 
for which it has an address.

If and only if NTLP cannot heal the break at its level, it notifies the NSLP 
application, which must then initiate its own recovery action.  That is where quick 
updating of new NSLP nodes and automatic dropping of stale state in NSLP nodes lost 
from the path become requirements.

Do I have the right picture?

Georgios Karagiannis wrote:
>>I think the consequences of what you're saying are that if there is a
> 
> change of
> 
>>1) at each node where the NSLP application is present, NTLP must notify
> 
> the NSLP
> 
>>application that a change has occurred.  I assume indications of change
> 
> are
> 
>>propagated between NTLP nodes along the path, so NTLP nodes remote from
> 
> the point of
> 
> level;
>>3) contrary to what George has been proposing, it is therefore not
> 
> possible to
> 
>>>adjacent entity and there is no other NEs between).  NTLP is the means
> 
> for
> 
>>>According to me, Georgios' example is an one of the general case : there
> 
> is
> 
>>>>Georgios' example raises this question: is NTLP used to maintain the
> 
> path
> 
>>>between
>>>
>>>
>>>>successive NSLP nodes, or is it used to maintain an end-to-end path
> 
> which
> 
>>>may
>>>
>>>
>>>>latter is the case, the implication for NSLP is that there has to be a
> 
> way
> 
>>>to bring
>>>
>>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 21 May 2003 15:42:38 +0200

Hi Tom

I think that your description is right!
However, I do not know what kind of healing process you have
in mind. The soft state procedures can be considered as a healing process.
In my opinion, when, per signaling application, a NTLP state and a NSLP
state are used
within one NSIS entity then the NTLP and NSLP healing process(es), on each
NSIS entity,
are very much inter-related.
Thus quick updating of new NSLP nodes and automatic dropping of stale state
in NSLP nodes lost
from the path are signifficant issues.

Best Regards,
Georgios

---

From: Tom Taylor <[email-masked]>
Date: Wed, 21 May 2003 11:17:36 -0400

I'm realizing as I think about it that various healing procedures are possible. 
Depending on the procedure, NTLP can act autonomously or NSLP would have to 
coordinate recovery.  I expect I'd better learn more about how these things are done 
in practice before I go further in my speculations.

So I'll drop this discussion, noting that we have agreed on two requirements at the 
NSLP level.

Georgios Karagiannis wrote:
>>distinguished from the sequence of NSLP nodes for a particular 
>>application.  Obviously these are linked, but to the extent that you can have
>>intervening NTLP nodes that do not also support the particular NSLP application,
 >>the NTLP topology can change while leaving the NSLP-level topology intact.  For
 >>this to happen, NTLP would have to have maintenance of the NSLP topology as an
 >>explicit goal. That is, in the event of a break, NTLP searches for an alternate
 >>route to the next NSLP node, for which it has an address.
>>
>>If and only if NTLP cannot heal the break at its level, it notifies the
>>NSLP application, which must then initiate its own recovery action.  That is
>>where quick updating of new NSLP nodes and automatic dropping of stale state
 >>in NSLP nodes lost from the path become requirements.
>>
...

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 21 May 2003 20:45:55 +0200

Hi Tom,

I agree with you about there are NSLP's topology and NTLP's topology. But
NLTP's topology changes then NSLP's topology can also change when NSLP can
"lay on" NTLP at some nodes. I don't think it's important to talk about
this, but just a justification.

> So I'll drop this discussion, noting that we have agreed on two
requirements at the

Best regards

Nary Tra
ENST, Paris
(0033) (0)1 45 81 71 06