Subject: [NSIS] Re: NSIS & Mobility

From: Sung-Hyuck Lee <[email-masked]>
Date: Mon, 27 Feb 2006 18:26:46 +0900

Hi Cornelia,

Sorry for too much late response. Thank you for your valuable comments.
Please refer to my comments in line (SHL).

Warm regards, 

Sung-Hyuck

----- Original Message ----- 
From: "Kappler, Cornelia" <[email-masked]>
To: "Seong-Ho Jeong" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 13, 2006 3:20 AM
Subject: NSIS & Mobility

> 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. 

[SHL] CD flag bit can be used to prevent NEs to unnecessarily 
perform CRN discovery processing, not to incorrectly perceive it is CRN.
Actually, IMO, CRN Discovery flag is more useful in the case of multihoming. 
In the multihoming scenarios, several CRNs can be discovered because 
of multiple paths. In this case, which CRN is in charge of State Update 
should be considered.

> (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.

[SHL] In the case of NI's handover, the old access router (AR) can be in 
charge of a role of proxying the NI (the mobile node). If the scenario that NI 
initiates teardown messages to remove the old state on the old path needs 
to be considered, the old AR as a proxy of the NI needs to tear down the 
old states on the old path.

> - "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

[SHL] You seem to misunderstand the identifier, NSLP_Br_ID. As you 
mentioned, the different branches were made by the processing of 
Message Routing State. We don't need to make an explicit identifier for 
CRN discovery. That is, NSLP_Br_ID is just a name representing those 
branches that are made by the processing of Message Routing State. 

> 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

[SHL] Yes. IMO, the table is also necessary to tear down the old state on 
the old path.

> 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. 

[SHL] As mentioned, the NSLP_Br_ID is created by the processing of 
Message Routing Association between two NSIS nodes. Which branch is
new can be identified by the counter value of NSLP_Br_ID. For example, 
as shown in Figure 2 of the mobility draft, each NSLP_Br_ID has a value 
of counter: #1, or #2. This value enables which signaling messages are 
new or old. Flow_ID can also be used to distinguish signaling messages.
If any explicit tear-down message is not used to remove the old states,
there can exist two more states or signaling messages at CRN. 

> - "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

[SHL] In scenarios of ping-pong type handover, which node is CRN can 
more easily be determined if mobility_event_counter (MEC) field of Mobility 
Object is used. Eventually, it can expedite the CRN discovery and State 
Update in mobility environments. 

> 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

[SHL] Sure, the ping-pong type handover-related issues may not be critical.
This is why the authors of the mobility draft think of the Mobility Object as
optional parts. Please the see the last paragraph of Section 4.2.2.

> (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.

[SHL] As you mentioned, Handover_Init (HI) field of the Mobility identifier 
can be used to resolve the last node detection-related issue. IMO, the 
message including HI field needs to be sent to CRN from the old AR if
adjusting the timer value of soft state is required. That is, If it is 
difficult to use any explicit teardown message due to the 
authorization-related issues with teardown described in Section 3.2.2 (3),
an appropriate timer value of soft state needs to be set at nodes on the 
old path to alleviate the double reservation problem. Concerning DoS 
attacks, more clarification seems to be needed.

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis