Subject: [NSIS] NSIS & Mobility

From: "Kappler, Cornelia" <[email-masked]>
Date: Thu, 12 Jan 2006 19:20:48 +0100

Hi Sung-Hyuck and Seong-Ho, and other "NSIS & Mobility" authors, 

recently I've been studying your draft
http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobili
ty-signaling-03.txt and have some questions:

Apparently you are proposing three enhancement to the existing NSIS
protocols. I am not sure they are necessary, see below. Furthermore -
and this is another main feedback - it should be made very clear in the
draft where you are proposing new things, and where you are discussing
already existing NSIS features. Very helpful would be a conclusion
section that states "this draft proposes the following enhancements to
the GIST and NSLP specifications.. "

- "CD flag bit" (Sec. 5.1.4.1). I think this is set by the Crossover
Node (CRN) when it discovers it is the CRN. Appart from the name (bit
AND flag is redundant), I dont understand what the use is of this flag. 
(i) Is it to prevent other NEs to wrongly think they are the CRN? I dont
think so: To my understanding a CRN identifies itself as being the CRN
because it has two interfaces to which the same session seems to be
incoming/outgoing, with a different flow ID attached to each interface.
There is no danger of any NE wrongly thinking it might be the CRN. This
situation is not changed in tunnelling scenarios. 

(ii) Is it to inform the NI or NR (or NEs) that the CRN has been found?
I dont think NEs in general are interested in this information. The NI
may have use for this in order to start tearing down the reservation
along the old section of the path. However I am not sure we are at all
considering this scenario (the NI initiating the tear down),
particularly since the NI may not be able to access the old path anymore
because it moved to a new access router.

- "NSLP_Br_ID" (Sec 4.2.2). This is an identifier for identifying
different branches of the same session on a given NE (i.e. a CRN). I
think this is redundant information. On GIST level, differnent branches
are already identified by different Message Routing State (i.e. the next
/ previous NSIS peers are different). It is interesting though that for
the CRN the table containing message routing state may need two entries
for next/previous NSIS peer for a single session, as long as the old
section of the path is not yet torn down. Even if the branch identifier
was useful it doesnt seem clear who sets it, i.e. which node determines
it is currently signaling along a new branch for an existing NSIS
session. Finally, it seems to me two branches for one session should be
a rather transient phenomenon. I.e. only one of them should really be
active at a given time. 

- "mobility object" (Sec 4.2.2). This is included (by the NI?) to alert
some other node (which?) that a mobility event took place. It is defined
to "expedite CRN discovery" - how? Why would the discovery be more
rapid? Such an object may indeed be useful, however the motivation given
relates mostly to solving the problem of ping-pong type handover which I
am not sure is such an urgent problem to solve. Another motivation is
(Sec. 5.5) apparently preventing time out of a session during the time a
mobile node is performing the handover. Is the idea that before handover
starts, the mobile node includes this object in order to inform all NEs
that they should not tear down the state even if the next refresh fails?
Probably it would be sufficient to inform the access router, because it
can reply to refreshes. No need to inform all NEs. But even if you
restrict it to the access router, I am sure there are security problems
with it (DoS attacks etc). Or may be I'be been misinterpreting your
intention.

Looking forward to your feedback, best regards, Cornelia
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis