Subject: RE: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5)ofMobility Draft

From: "Shivanajay Marwaha" <[email-masked]>
Date: Tue, 28 Feb 2006 18:42:27 +0800

Dear Sung-Hyuck,

Thanks for your reply. Please see my comments inline [SHIV].

Thanks,
Shivanajay   

> -----Original Message-----
> From: Sung-Hyuck Lee [mailto:[email-masked]] 
> Sent: Tuesday, February 28, 2006 3:51 PM
> To: Shivanajay Marwaha; [email-masked]
> Subject: Re: [NSIS] Some More Suggestions on Multi-homing 
> (section 5.2.5)ofMobility Draft
> 
> Hi Shivanajay,
>  
> Please refer to my comments.
>  
> Thanks,
>  
> Sung-Hyuck
>  
> ----- Original Message -----
> From: "Shivanajay Marwaha" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, February 27, 2006 7:13 PM
> Subject: RE: [NSIS] Some More Suggestions on Multi-homing 
> (section 5.2.5)ofMobility Draft
> 
> > Dear Seong-Ho,
> >
> >Thanks for your reply. Regarding your question on CRN  
> >operation/discovery failure, we are actually referring to 
> the mobility  
> >scenario when multiple interfaces are used for one session 
> (e.g. load  
> >balancing as indicated in section 5.2.5 of the mobility 
> applicability  
> >draft). Detailed description of the issue is as
> > following:
> > 
> > As described in Section 5.2.5, 2nd paragraph of the mobility draft, 
> > the MN is using two paths for the same session (i.e. Path 1 
> and Path 
> > 2). In this case, as suggested by section 5.2.5 of the 
> mobility draft, 
> > same Session ID with different Flow IDs will be used for 
> the two paths.
> > 
> > When one of these paths (Path 2) experiences a mobiity event, e.g.
> > one of the multiple interfaces of the MN handovers to 
> another network, 
> > a new path is resulted, i.e. Path 3. Yet, NSIS will use the same 
> > Session ID with a new Flow ID for this path. Therefore, two 
> types of 
> > CRNs will now exist:- CRN for Path 1 and Path 3; and CRN 
> for Path 2 and Path 3.
> >
> > If the NSIS signaling over Path 3 triggers a CRN discovery, the CRN 
> > discovery may lead to discovery of a QNE which is a CRN for 
> path 1 and 
> > Path 3 only, instead of correctly identifying a QNE which 
> is a CRN for 
> > Path 2 and Path 3. This is because the current NSIS CRN Discovery 
> > Procedure does not provide information about whether a CRN 
> is caused 
> > by the mobility event or multiple interfaces.
> 
> [SHL] "CD (CRN_Discovery) flag" described in Section 5.1.4.1 
> can solve this issue because the CD flag can prevent NEs to 
> incorrectly perform the process of CRN discovery. For 
> example, once CRN between Path 2 and Path 3 is discovered, 
> the CD flag is set and thus downstream NEs don't perform the 
> process of CRN discovery. Therefore, the CRN discovery 
> between Path 1 and Path 3 doesn't occur.
>  
> After handover, if a merging point between Path 1 and Path 3 
> exists before the CRN between Path 2 and Path 3, the merging 
> point between Path 1 and Path 3 becomes CRN and thus 'CD 
> flag' is set. The existing CRN (as downstream NE of the CRN 
> btw Path 1 and Path 3) between Path 1 and Path 2 can remove 
> the old state on the Path 2 when it checks the CD flag 
> included in NSIS signaling message from upstream NEs. In this 
> case, the existing CRN needs to remove the old state through 
> checking the CD flag.

[SHIV] As mentioned above, for the CRN (between Path 1 and Path 2) to
remove/update the old state, it needs to know which path is the old
state (e.g.
whether it is Path 1 or Path 2). However, the CD Flag does not contain
this
information. Therefore, the CRN (between Path 1 and Path 2) would not be
able
to identify the correct path state to remove using the CD Flag alone.

Secondly, the discovered CRN has no way to know whether it is a CRN of
mobility
event (i.e. between Path 2 and Path 3) or a CRN of multiple paths (e.g.
between
Path 1 and Path 3). And, this is the root of the issue. Changing the CRN
behavior and using CD Flag does not solve it fundmentally, and may cause
further problems. For example, the CRN behavior described above
obviously does
not fit for non-multihoming cases.    
> 
> > The problem encountered in this case is that the discovered 
> CRN would 
> > have no information to decide its proper action (whether it is a 
> > mobility event, or it's a multihoming case). There is a 
> more thorough 
> > analysis of this problem in section 4.1 of
> > draft-sanda-nsis-path-type-03
> > [http://tools.ietf.org/wg/nsis/draft-sanda-nsis-path-type-03.txt]
> >
> > The above problem is an important issue to be considered in the 
> > mobility draft as this scenario is very common and 
> realistic. The text 
> > sent earlier provides a brief  description of this problem. 
> If there 
> > is a need for further clarification on this problem, we can provide 
> > more/amended text for that.
>  
> [SHL] I think this issue needs to further be discussed in the 
> mobility draft.

[SHIV] Correct, we need to discuss this issue/scenario further in the
mobility draft as it is a valid issue. If needed we can provide
relavent text for the draft, kindly let us know. 

> [SHL] What do you think differences between Path type and CD flag?
> 
 
[SHIV] The CD Flag and Path Type ID are actually introduced for
different
purposes. The CD Flag (as what we understand) is for CRN discovery
process, e.g.
to avoid unnecessary further CRN discovery process after a CRN is
already
identified. 

However CD Flag does not provide information about the relationship
between
different paths (whether they are old and new paths resulted from a
mobility
event, e.g. Path 2 & Path 3; or they are paths simultaneously used for a
session,
e.g. Path 1 and Path 3). This is where the Path Type ID could be used
for. We
don't think that the CD Flag and Path Type ID conflicts with each other
since
they are addressing different issues. 

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