RE: [NSIS] NSIS mobility related issue # 1forcomment-CRNdiscovery-related issue

["Hancock, Robert" <robert.hancock at roke.co.uk>]

hi,

[consensus chunks snipped]

> > 2. GIMPS only associates state with flow/NSLP combinations. (It knows 
> > about sessions, but takes almost no notice of them. In particular, it 
> > really doesn't know whether sessions are associated with each other, 
> > or whether several flows are really associated with the same session, 
> > and it doesn't validate anything about what session identifiers
> > are used.)
> > This means that there are several scenarios where the CRN
> > which the NSLP is interested in cannot be detected by the
> > NTLP. One example would be where an old flow is replaced
> > by a new one with a difference path. The NSLP doesn't care
> > about this but the NTLP would see nothing here.
> >
> > A converse case would be that the NTLP detects a route
> > change for a flow, which the NSLP doesn't care about
> > (because the flow has been replaced and the NSLP is
> > letting it die away).
> > 
> > Another case is where there is a single flow and session
> > for which a potential route change is detected by the
> > NTLP at one node, but the NTLP doesn't actually know
> > where the true CRN is. (This is the situation discussed
> > in section 6.1 of the GIMPS spec.)
> 
> In Section 6.1.4 of the GIPMS draft, it was mentioned that
> NSLP peers are a single GIMPS hop apart. Does it mean that 
> GIMPS is closely coupled with NSLP? 

I'm not sure what you mean by this phrase, but it is true
that the GIMPS routing state is NSLP-dependent. (See further
below.)

> Is it possible to allow 
> different GIMPS states to be set up according to the type 
> of NSLP? I think this can be true if we take a look at 
> Figure 7 in Appendix B. 

This is correct (so far...)

> In this case, I think the CRN 
> discovery would not be too difficult if the messaging 
> association setup process is used. In other words, it may 
> not be too difficult to determine if the current node is 
> a CRN because the GIMPS can use the flow ID, session ID, and 
> NSLP ID as well as pointer which are already needed for messaging 
> association, and the GIMPS can let the involved NSLP know 
> the information to perform necessary actions immediately.. 
> Please correct me if I am wrong.

In some cases it is true that the CRN discovery by the NTLP
'just works'. The necessary conditions are:
*) The mobility event is the re-routing of a single flow, and
*) The detecting node actually is the CRN

But this doesn't cover all mobility cases; in particular,
it doesn't cover the case where mobility takes place above
the flow level, or where the detecting node is not the CRN
(i.e. it is possible for a node to think it is the CRN
when in fact it is not - in other words, a "false positive".
this is the problem discussed in GIMPS 6.1.)

robert h.

_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis